mysql临时表产生的执行效率问题改进
2014-05-07 15:25
246 查看
问题:
近日,线上mysql查出一个慢sql,每次都要查询1000ms以上,严重影响用户体验
今得空去诊断一番,记录如下:
sql原句:
解决问题:
由于对数据库优化一知半解,完全无从下手,只能求助度娘和谷哥了,试验了各种方法,都不见效果
几番周折之后,最终把注意力集中到了临时表上,因为explain查看执行计划,可以看到Using temporary
MySQL在执行SQL查询时可能会用到临时表,一般情况下,用到临时表就意味着性能较低。
于是想办法修改sql语句,摒弃临时表,修改如下:
即把语句给拆分成两个sql语,用in操作拼接
本机测试:
优化前执行时间1040ms,优化后执行时间:85ms,执行速度是原来的12倍多!赞
PS:
常理我们都会排斥用in操作,用union替换,那为什么这里用in会更快呢?
带着问题,接着去网上找,原来:
sql执行会生成一个巨大的临时表,当内存放不下时,要全部copy 到磁盘,导致IO飙升,时间开销增大。
额外收获知识收藏如下:
临时表存储
MySQL临时表分为“内存临时表”和“磁盘临时表”,其中内存临时表使用MySQL的MEMORY存储引擎,磁盘临时表使用MySQL的MyISAM存储引擎;
一般情况下,MySQL会先创建内存临时表,但内存临时表超过配置指定的值后,MySQL会将内存临时表导出到磁盘临时表;
使用临时表的场景
1)ORDER BY子句和GROUP BY子句不同, 例如:ORDERY BY price GROUP BY name;
2)在JOIN查询中,ORDER BY或者GROUP BY使用了不是第一个表的列 例如:SELECT * from TableA, TableB ORDER BY TableA.price GROUP by TableB.name
3)ORDER BY中使用了DISTINCT关键字 ORDERY BY DISTINCT(price)
4)SELECT语句中指定了SQL_SMALL_RESULT关键字 SQL_SMALL_RESULT的意思就是告诉MySQL,结果会很小,请直接使用内存临时表,不需要使用索引排序 SQL_SMALL_RESULT必须和GROUP BY、DISTINCT或DISTINCTROW一起使用 一般情况下,我们没有必要使用这个选项,让MySQL服务器选择即可。
直接使用磁盘临时表的场景
1)表包含TEXT或者BLOB列;
2)GROUP BY 或者 DISTINCT 子句中包含长度大于512字节的列;
3)使用UNION或者UNION ALL时,SELECT子句中包含大于512字节的列;
表的设计原则
使用临时表一般都意味着性能比较低,特别是使用磁盘临时表,性能更慢,因此我们在实际应用中应该尽量避免临时表的使用。 常见的避免临时表的方法有:
1)创建索引:在ORDER BY或者GROUP BY的列上创建索引;
2)分拆很长的列:一般情况下,TEXT、BLOB,大于512字节的字符串,基本上都是为了显示信息,而不会用于查询条件, 因此表设计的时候,应该将这些列独立到另外一张表。
SQL优化
如果表的设计已经确定,修改比较困难,那么也可以通过优化SQL语句来减少临时表的大小,以提升SQL执行效率。
常见的优化SQL语句方法如下:
1)拆分SQL语句
临时表主要是用于排序和分组,很多业务都是要求排序后再取出详细的分页数据,这种情况下可以将排序和取出详细数据拆分成不同的SQL,以降低排序或分组时临时表的大小,提升排序和分组的效率,我们的案例就是采用这种方法。
2)优化业务,去掉排序分组等操作
有时候业务其实并不需要排序或分组,仅仅是为了好看或者阅读方便而进行了排序,例如数据导出、数据查询等操作,这种情况下去掉排序和分组对业务也没有多大影响。
如何判断使用了临时表?
使用explain查看执行计划,Extra列看到Using temporary就意味着使用了临时表。
小结:
可见, 完全颠覆了对in操作符的认识,凡事儿都是要分情况讨论的
近日,线上mysql查出一个慢sql,每次都要查询1000ms以上,严重影响用户体验
今得空去诊断一番,记录如下:
sql原句:
SELECT r.object_id AS cardId, count(1) AS attachs FROM hzresource_object r LEFT JOIN ( SELECT card_id FROM card_member WHERE user_id = #uid# and card_member.deleted=0 UNION SELECT card_id FROM card_subscribed where user_id = #uid# and card_subscribed.deleted=0 ) m ON r.object_id = m.card_id WHERE r.object_type = #objectType# AND r.deleted = 0 GROUP BY r.object_id;
解决问题:
由于对数据库优化一知半解,完全无从下手,只能求助度娘和谷哥了,试验了各种方法,都不见效果
几番周折之后,最终把注意力集中到了临时表上,因为explain查看执行计划,可以看到Using temporary
MySQL在执行SQL查询时可能会用到临时表,一般情况下,用到临时表就意味着性能较低。
于是想办法修改sql语句,摒弃临时表,修改如下:
SELECT r.object_id AS cardId, count(1) AS attachs FROM hzresource_object r WHERE r.object_type = #objectType# AND r.deleted = 0 and r.object_id in ( SELECT card_id FROM card_member WHERE user_id = #uid# and card_member.deleted=0 UNION SELECT card_id FROM card_subscribed where user_id = #uid# and card_subscribed.deleted=0 ) GROUP BY r.object_id;
即把语句给拆分成两个sql语,用in操作拼接
本机测试:
优化前执行时间1040ms,优化后执行时间:85ms,执行速度是原来的12倍多!赞
PS:
常理我们都会排斥用in操作,用union替换,那为什么这里用in会更快呢?
带着问题,接着去网上找,原来:
sql执行会生成一个巨大的临时表,当内存放不下时,要全部copy 到磁盘,导致IO飙升,时间开销增大。
额外收获知识收藏如下:
临时表存储
MySQL临时表分为“内存临时表”和“磁盘临时表”,其中内存临时表使用MySQL的MEMORY存储引擎,磁盘临时表使用MySQL的MyISAM存储引擎;
一般情况下,MySQL会先创建内存临时表,但内存临时表超过配置指定的值后,MySQL会将内存临时表导出到磁盘临时表;
使用临时表的场景
1)ORDER BY子句和GROUP BY子句不同, 例如:ORDERY BY price GROUP BY name;
2)在JOIN查询中,ORDER BY或者GROUP BY使用了不是第一个表的列 例如:SELECT * from TableA, TableB ORDER BY TableA.price GROUP by TableB.name
3)ORDER BY中使用了DISTINCT关键字 ORDERY BY DISTINCT(price)
4)SELECT语句中指定了SQL_SMALL_RESULT关键字 SQL_SMALL_RESULT的意思就是告诉MySQL,结果会很小,请直接使用内存临时表,不需要使用索引排序 SQL_SMALL_RESULT必须和GROUP BY、DISTINCT或DISTINCTROW一起使用 一般情况下,我们没有必要使用这个选项,让MySQL服务器选择即可。
直接使用磁盘临时表的场景
1)表包含TEXT或者BLOB列;
2)GROUP BY 或者 DISTINCT 子句中包含长度大于512字节的列;
3)使用UNION或者UNION ALL时,SELECT子句中包含大于512字节的列;
表的设计原则
使用临时表一般都意味着性能比较低,特别是使用磁盘临时表,性能更慢,因此我们在实际应用中应该尽量避免临时表的使用。 常见的避免临时表的方法有:
1)创建索引:在ORDER BY或者GROUP BY的列上创建索引;
2)分拆很长的列:一般情况下,TEXT、BLOB,大于512字节的字符串,基本上都是为了显示信息,而不会用于查询条件, 因此表设计的时候,应该将这些列独立到另外一张表。
SQL优化
如果表的设计已经确定,修改比较困难,那么也可以通过优化SQL语句来减少临时表的大小,以提升SQL执行效率。
常见的优化SQL语句方法如下:
1)拆分SQL语句
临时表主要是用于排序和分组,很多业务都是要求排序后再取出详细的分页数据,这种情况下可以将排序和取出详细数据拆分成不同的SQL,以降低排序或分组时临时表的大小,提升排序和分组的效率,我们的案例就是采用这种方法。
2)优化业务,去掉排序分组等操作
有时候业务其实并不需要排序或分组,仅仅是为了好看或者阅读方便而进行了排序,例如数据导出、数据查询等操作,这种情况下去掉排序和分组对业务也没有多大影响。
如何判断使用了临时表?
使用explain查看执行计划,Extra列看到Using temporary就意味着使用了临时表。
小结:
可见, 完全颠覆了对in操作符的认识,凡事儿都是要分情况讨论的
相关文章推荐
- mysql临时表产生的执行效率问题改进(转)
- mysql 临时表 效率问题改进
- mysql 5.6 order by Limit执行效率问题
- VC+ADO+MySQL执行select count(*)效率问题
- MySQL 5.1的中文支持的一个改进,从MySQL 4.1开始不支持中文路径,文件名的问题解决了
- mysql中RAND()随便查询记录效率问题和解决的方法分享
- Mysql bench执行sql语句批量操作数据所遇到的问题
- 一个诡异的crontab执行提示1045错误码的MySQL问题定位
- mysql插入数据产生中文乱码问题
- JQuery 执行效率问题
- MySQL查看SQL语句执行效率
- 问题3:mysql explain执行计划查看
- mysql版本不同所导致SQL语句执行错误的问题
- mysql查看慢查询、分析执行SQL的效率
- php 自定义函数和原生函数执行效率问题
- QT连接mysql、oracle数据库可执行程序的移植性问题
- Linux cron执行mysql失败(编码问题)
- mysql 分析查找执行效率慢的SQL语句
- 关于x=x+1、x+=1、x++的执行效率问题
- MYSQL 执行Insert语句throws "The table 'xxx' is full" 的问题分析及解决办法