OrderBy 和Select的错误使用导致的慢sql——一次问题排查记录

引言

使用Mysql的时候，我们总会通过设置索引来提高查询效率，但是在某些情况下，即便索引存在，也可能会由于数据量的变化而导致我们预期的索引不生效，笔者遇到了这样的问题。不同数据量下执行计划使用的索引不一样，而索引的差异则导致了最终查询时间的巨大差异。

本文分为三部分，第一部分简单回顾一下Mysql中非常有名的“三星索引”，第二部分则是具体描述笔者遇到的问题，第三部分则会提出具体的解决方案以及方法建议。

Mysql中的三星索引

• 索引将相关的记录放到一起获得一星
  没有必要为where中的每一条件单独建立索引，可以把条件中的多列一起形成一个组合索引。

• 如果索引中的数据顺序和查找中的排列顺序一致获得两星
  order by 中的列，与where条件中的列，都存在于索引中，且order by 的列为最前列（索引第一前缀）。

• 如果索引中的列包含了查询中需要的全部列则获得三星
  索引中的列包含了查询中需要的全部列。同时，将易变的列变在最后。这样索引包含查询所需要的数据列，不再进行回表查询。这样的索引效率是极高的。

  简单点来说，也就是这样一个sql

  select columnA, columnB from T_Test where columnA in () order by columnA，如果我们在ColumnA, ColumnB上存在一个组合索引，那么这就是一个三星索引。

  通过三星索引，我们也能够明白一件事情——一个Sql只能使用一个索引，如果order by和where条件中的列不一致，则Mysql也会最终确定一个。而笔者遭遇的问题，也就是Order by和where中可以使用的索引不一致导致的。

执行计划错误导致的慢Sql

首先来看下表的建表语句（简化后），

CREATE TABLE `T_S