记录一次简单的SQL调优引发的学习和思考

现在有一张会员表，表的结构如下：

不出所料，索引的确是用上了，难道，我要在每个索引字段后面都加上deleted_at才可以？一时间我产生了这样的想法，但是马上否定了，因为平时工作中大家并没有这种习惯，肯定是别的地方出现了问题，导致索引失效了。我重新把platform_id索引后的deleted_at字段去掉，恢复到原来的索引。然后开启了OPTIMIZER_TRACE用于跟踪mysql优化器分析SQL语句的优化过程：

set optimizer_trace="enabled=on";
show variables like 'optimizer_trace';

执行结果如图：

然后执行以下语句查询跟踪结果树：

select * from INFORMATION_SCHEMA.OPTIMIZER_TRACE \G;

将json树复制到线上网站后解析发现：

好家伙，优化器在分析可选索引时最终并没有选择我想要的索引，但是原因是unknown，并没有获得什么有用的信息。

后来，我在网上复习了一下导致索引失效的情况总结，突然间注意到这个：

通过进行对比，还是能够发现不少问题的，以下为结论部分：

1. 第一条语句，访问类型为ALL，走的是全表扫描；Extra信息是Using where，意味着Mysql服务器在存储引擎检索后再进行过滤，此过滤发生在Mysql Server层。
2. 第二条语句，访问类型为index，把索引树扫描了一遍；Extra信息是Using where，Using index，表示做到了覆盖索引但需要进行过滤。
3. 第三条语句，访问类型为ref，用到了索引查找，它返回所有匹配某个单个值的行；Extra信息是Using index，表示做到了覆盖索引。
4. 第四条语句，访问类型为ref，同上；Extra信息是Using where，表示需要进行过滤，但很明显不一样的是，此处没有做到覆盖索引。

要完全理解上述四种情况的差别，需要先熟悉不同访问类型的区别，要理解Extra信息具体表示的意思，还需要理解覆盖索引、回表查询、索引下推等概念，不清楚的可以看看文章最后的参考文章。
总结这次之所以没有第一时间发现真正的问题所在，是因为没有注意到在执行第二条语句时，访问类型为index，也就是说仅仅扫描了整个索引树，但是没有利用到索引查找，在性能上是远低于ref访问类型的。

拓展延申：那么，如果我单独给deleted_at字段加上索引？数据库结构如下图，会发生什么情况呢？

1. 第一种情况，也即导致platform_id索引失效的情况，访问类型属于ref，走的是deleted_at索引，Extra信息包含Using where，但没有Using index，证明没法做到覆盖索引，需要回表查询进行过滤，此处需要过滤的字段就是platform_id字段。（注：这里的Extra同时还出现了Using index condition，由于是伴随着Using where出现的所以也不仅仅是ICP，属于一种比较特殊的情况，能力和篇幅有限所以就先不讨论这种特例了）
2. 第二种情况，也即platform_id索引没有失效的情况，访问类型属于ref，注意并不是index_merge，有人可能会认为这里mysql优化器会采用索引合并的方法，但事实上mysql优化器选择了走platform_id索引并通过回表查询出deleted_at进行过滤。因此Extra信息显示的是Using where。
3. 至于什么情况才才会用到index_merge，可以参考下面这种情况：

index merge 技术简单的说，就是对多个索引分别进行条件扫描，然后将它们各自的结果进行合并(intersect/union)。但并非只有or的情况才会使用index merge，and的情况也有可能，需要看具体的数据（例子待补充）。

最后需要注意的是，不建议单独给deleted_at字段添加索引，因为可能会导致查询性能下降，具体案例可以参考这篇文章：

https://www.jianshu.com/p/aef...

其它参考文章：
常见索引失效场景： https://blog.csdn.net/weixin_...
Mysql优化器跟踪： https://blog.csdn.net/hehuyi_...
访问类型type级别分析： https://www.cnblogs.com/sweet...
执行计划Extra对比分析： https://www.cnblogs.com/wy123...
InnoDB与MyISAM 聚集索引与非聚集索引： https://blog.csdn.net/qq_2858...
索引覆盖、回表查询以及索引下推： https://www.cnblogs.com/youzh...
MySQL的server层和存储引擎层交互： https://juejin.cn/post/684490...
《高性能Mysql》： https://book.douban.com/subje...