本文探讨了SQL查询使用索引后仍然出现慢查询的问题。即使查询使用了索引，是否进入慢查询取决于执行时间。全索引扫描可能导致查询变慢，索引的过滤性需要足够好以减少扫描行数。回表操作也可能带来额外的性能开销。文章通过案例分析了如何优化查询，包括考虑更优的索引设计和利用MySQL的index condition pushdown优化。
经常有同学问我，我的一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。
另外插入一个题外话，个人认为团队要合理的使用ORM，可以参考 ORM的权衡和抉择。合理利用的是ORM在面向对象和写操作方面的优势，避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当别论)，因为ORM屏蔽了太多的DB底层的知识内容，对程序员不是件好事，对性能有极致追求，但是ORM理解不透彻的团队更加要谨慎。
案例剖析
言归正传，为了实验，我创建了如下表：
该表有三个字段，其中用id是主键索引，a是普通索引。
首先SQL判断一个语句是不是慢查询语句，用的是语句的执行时间。他把语句执行时间跟long_query_time这个系统参数作比较，如果语句执行时间比它还大，就会把这个语句记录到慢查询日志里面，这个参数的默认值是10秒。当然在生产上，我们不会设置这么大，一般会设置1秒，对于一些比较敏感的业务，可能会设置一个比1秒还小的值。
语句执行过程中有没有用到表的索引，可以通过explain一个语句的输出结果来看KEY的值不是NULL。
我们看下 explain select * from t; 的KEY结果是NULL
explain select * from t where id=2; 的KEY结果是PRIMARY，就是我们常说的使用了主键索引
explain select a from t; 的KEY结果是a，表示使用了a这个索引。
虽然后两个查询的KEY都不是NULL，但是最后一个实际上扫描了整个索引树a。
假设
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
