MySQL慢查询现象解决案例 目录 背景 1.查看上述语句的执行计划 2.测试模拟 背景 线上慢查询日志监控,得到如下的语句: 发现:select doc_text from t_wiki_doc_text where doc_title = '谢泽源'; 这条语句昨天执行特别的慢 1.查看上述语句的执行计划 mysql explain
目录
- 背景
- 1.查看上述语句的执行计划
- 2.测试模拟
背景
线上慢查询日志监控,得到如下的语句:
发现:select doc_text from t_wiki_doc_text where doc_title = '谢泽源'; 这条语句昨天执行特别的慢
1.查看上述语句的执行计划
发现了Impossible where noticed after reading const tables,这是一个有趣的现象?(经查找,这个会全表扫描)
解释原因如下:
根据主键查询或者唯一性索引查询,如果这条数据没有的话,它会全表扫描,然后得出一个结论,该数据不在表中。
对于高并发的库来说,这条数据,会让负载特别的高。
查看线上的表结构,也印证的上述说法:
对此,我在自己的数据库里面,做了一个测试。
2.测试模拟
1).建立一个有唯一索引的表。
2).插入两条数据
3).分析一个没有数据记录的执行计划。(例如select name from zsd01 where name ='c'; )
发现跟上述情况一模一样。
4.) 修改表结构为只有一般索引的情况。
5.) 查看执行计划。
发现,就正常走了一般索引,rows=1的执行开销。
结论:从上述的例子和现象可以看出,如果数据不用唯一的话,普通的索引比唯一索引更好用。
到此这篇关于MySQL慢查询现象解决案例的文章就介绍到这了,更多相关MySQL慢查询内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!