博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
对于Mysql大量数据查询速度慢的问题
阅读量:7061 次
发布时间:2019-06-28

本文共 2601 字,大约阅读时间需要 8 分钟。

hot3.png

1.如果mysql数据量过大,当查询的时候耗时比较长,则会影响页面数据展示。给客户的直观反应的:

点击了某个查询功能,结果等了差不多十几秒才反应出来,这样的体验感太差了。

2.为了增加反应速度。一般来是建立索引,如我现在的查询语句:

SELECT                aa.INDI_NAME,                aa.gg,                aa.gp,                aa.pn,                bb.report_name            FROM                (                    SELECT                        T.INDI_ID,                        T.INDI_NAME,                       SUM(CASE WHEN T.AREA_ID =2501 THEN T.INDI_VALUE ELSE 0 END) gg,                       SUM(CASE WHEN T.AREA_ID =2502 THEN T.INDI_VALUE ELSE 0 END) gp,                       SUM(CASE WHEN T.AREA_ID =2503 THEN T.INDI_VALUE ELSE 0 END) pn              FROM  VW_ST_INDEX_INST_DAY_2310_DT_X T             WHERE T.MONTH_NO = '201708'               AND T.DATE_NO = '20170831'               AND T.LATN_ID = '1100'               AND T.TYPE_ID < '99'               AND T.REPORT_ID = '23100104' -- 该至是个变至1到4变化 例如:23100101,23100102,23100103,23100104             GROUP BY T.INDI_ID, T.INDI_NAME            UNION ALL            SELECT T.INDI_ID, T.INDI_NAME,                       SUM(CASE WHEN T.AREA_ID =2501 THEN T.INDI_VALUE ELSE 0 END) gg,                       SUM(CASE WHEN T.AREA_ID =2502 THEN T.INDI_VALUE ELSE 0 END) gp,                       SUM(CASE WHEN T.AREA_ID =2503 THEN T.INDI_VALUE ELSE 0 END) pn              FROM  VW_ST_INDEX_INST_DAY_2310_DT_X T             WHERE T.MONTH_NO = '201708'               AND T.LATN_ID = '1100'               AND T.DATE_NO <= '20170831'               AND T.TYPE_ID ='99'               AND T.REPORT_ID = '23100104'  -- 该至是个变至1到4变化 例如:23100101,23100102,23100103,23100104             GROUP BY T.INDI_NAME, T.INDI_ID) aa,            (SELECT                *             from dim_report_conf             where report_id = '23100104') bb  -- 该至是个变至1到4变化 例如:23100101,23100102,23100103,23100104

 

如下反应速度比较慢是2秒

 

建立索引:

索引语句:

CREATE INDEX vwIndexIdLAAAA on vw_st_index_inst_day_2310_dt_x (REPORT_ID,LATN_ID,DATE_NO);

 

然后再次或者多次查询就变成了0.009秒了

 

所以还是建立索引比较快。

如果出现这种错误:

则是你数据库字段太长了,需要修改具体的长度计算规则如下:

经过查询才知道,是Mysql的字段设置的太长了,于是我把这两个字段的长度改了一下就好了。 

建立索引时,数据库计算key的长度是累加所有Index用到的字段的char长度后再按下面比例乘起来不能超过限定的key长度1000: 
latin1 = 1 byte = 1 character 
uft8 = 3 byte = 1 character 
gbk = 2 byte = 1 character 
举例能看得更明白些,以GBK为例: 
CREATE UNIQUE INDEX `unique_record` ON reports (`report_name`, `report_client`, `report_city`); 
其中report_name varchar(200), report_client varchar(200), report_city varchar(200) 
(200 + 200 +200) * 2 = 1200 > 1000,所有就会报1071错误,只要将report_city改为varchar(100)那么索引就能成功建立。 
如果表是UTF8字符集,那索引还是建立不了。

(200 + 200 +200) * 3 = 1800 大于提示信息字段。

 

转载于:https://my.oschina.net/u/1399599/blog/1536886

你可能感兴趣的文章
lLinux学习笔记之apache及论坛的发布
查看>>
上三角
查看>>
C# 多线程学习系列二
查看>>
简单词法分析器的实现
查看>>
9-14NOIP模拟赛总结
查看>>
进程中的信号量
查看>>
Docker 快速入门教程
查看>>
centos7 xfs 文件系统配置quota 用户磁盘配额
查看>>
2019-1-5吃货联盟作业
查看>>
poj 1836 -- Alignment
查看>>
安卓中自定义并使用Volley框架请求网络
查看>>
Linux运维笔记-后端运行脚本
查看>>
Java数据类型、变量、运算符、语句。
查看>>
格式化输出函数:printf 那些事 (C语言)
查看>>
windows CE 6.0编译报BLDDEMO: There were errors building MY283错误解决办法
查看>>
FTP基础知识
查看>>
今天博客开通了
查看>>
web.xml中的*.jsp如果当welcome-file,eclipse在下次跑的时候不自动更新到tomcat中的问题(eclipse可以去死了)...
查看>>
jQuery 选择器
查看>>
NettyIO
查看>>