分析一个MySQL的异常查询的案例

问题

用户工单疑问：相同的语句，只是最后的limit行数不同。奇怪的是，limit 10 的性能比limit 100的语句还慢约10倍。

隐藏用户表信息，语句及结果如下

select f1 , sum(`f2`) `cnt` from t where f1 is not null and f3 = '2014-05-12' group by f1 order by `cnt` desc limit 10;

执行时间3 min 3.65 sec

select f1 , sum(`f2`) `cnt` from t where f1 is not null and f3 = '2014-05-12' group by f1 order by `cnt` desc limit 100;

执行时间1.24sec.

性能差距非常大！

分析
mysql tips：追查语句执行时最常用的方法，是通过explain来看语句的执行计划。 ?

更有冲击性的效果是通过缩小范围后，在这个数据下，limit 67和limit 68的执行计划相差很大。

两个执行计划：

limit 67
id: 1
select_type: simple
table: a
type: range
possible_keys: a,b,c
key: b
key_len: 387
ref: null
rows: 2555192
extra: using where; using temporary; using filesort
1 row in set (0.00 sec)

limit 68
id: 1
select_type: simple
table: a
type: ref
possible_keys: a,b,c
key: a
key_len: 3
ref: const
rows: 67586
extra: using where; using temporary; using filesort
1 row in set (0.00 sec)

可以看到，两个语句的执行计划不同：使用的索引不同。

mysql tips：explain的结果中，key表示最终使用的索引，rows表示使用这个索引需要扫描的行数，这是个估计值。

表中 索引a定义为 (f3, f4, f1, f2, f5); 索引b定义为(f1, f2, f3);

一个确认

虽然rows是估计值，但是指导索引使用的依据。既然limit 68能达到rows 67586,说明在第一个语句优化器可选结果中，也应该有此值，为什么不会选择索引a？
先确认一下我们上面的这个结论。

mysql tips：mysql语法中能够用force index 来强行要求优化器使用某一个索引。

explain select f1 , sum(f2) cnt from t force index(a) where f1 is not null and f3 = ‘2014-05-12' group by p order by cnt desc limit 67\g

id: 1
select_type: simple
table: a
type: ref
possible_keys:a
key: a
key_len: 3
ref: const
rows: 67586
extra: using where; using temporary; using filesort
1 row in set (0.00 sec)

顺便说明，由于我们指定了force index，因此优化器不会考虑其他索引，possible_keys里只会显示a。我们关注的是rows:67586。这说明在limit 67语句里，使用索引a也能够减少行扫描。

mysql tips：mysql优化器会对possiable_key中的每个可能索引都计算查询代价，选择最小代价的查询计划。

至此我们大概可以猜测，这个应该是mysql实现上的bug：没有选择合适的索引，导致使用了明显错误的执行计划。

mysql tips：mysql的优化器执行期间需要依赖于表的统计信息，而统计信息是估算值，因此有可能导致得到的执行计划非最优。

但要说明的是，上述tip是客观情况造成（可接受），但本例却是例外，因此优化器实际上可以拿到能够作出选择正确结果的数据(rows值)，但是最终选择错误。

原因分析

mysql优化器是按照查询代价的估算值，来确定要使用的索引。计算这个估算值的过程，基本是按照“估计需要扫描的行数”来确定的。

mysql tips：mysql在目前集团主流使用的5.1和5.5版本中只能使用前缀索引。

因此，使用索引a只能用上字段f3，使用索引b只能用上字段f1。rows即为使用了索引查到上下界，之后需要扫描的数据行数（估算值）。

上述的语句需要用到group和order by，因此执行计划中都有using temporary; using filesort。
流程上按顺序先计算使用索引a的查询代价。

之后依次计算其他possitabe_key的查询代价。由于过程中需要排序，在得到一个暂定结果后，需要判断是否有代价更低的排序方式(test_if_cheaper_ordering)。
与之前的大同小异，也是依靠估计扫描行数来计算代价。

在这个逻辑的实现过程中，存在一个bug：在估计当前索引的区分度的时候，没有考虑到前缀索引。

即：假设表中有50w行数据，索引b(f1,f2,f3)，则计算索引区分度时，需要根据能够用上的前缀部分来确定。比如f1有1000个不同的值，则平均每个key值上的记录数为500.如(f1,f2)有10000个同的值，则平均每个组合key上的记录数为50，若(f1,f2,f3)有50w个不同的值，则平均每个组合key上的记录数为1。

mysql tips：每个key上的记录数越少，说明使用该索引查询时效率最高。对应于show index from tbl 输出结果中的cardinality值越大。

在这个case下，索引b只能使用f1做前缀索引，但是在计算单key上的行平均值时用的是(f1,f2,f3)，这就导致估算用索引b估算的时候，得到的代价偏小。导致误选。

回到问题本身

1、 为什么limit值大的时候反而选对了呢？
这是因为在计算b的查询代价时，查询需要返回的行数limit_rows也参与乘积，若limit值较大，则计算出来的b的代价就会更大，反而会由于代价。值超过a，而导致优化器最终选择a。

2、 这个表有50w行数就，为什么limit相差为就差别这么大？
这与语句本身有关。这个语句中有group by，这就意味着每多limit一个值，实际上需要扫描更多的行n。 这里n为“表的总行数”/“表中不同的f2值”。
也就是说这个语句使得这个bug有放大作用。

解决方案

分析清楚后解决方法就比较简单了，修改代码逻辑，在执行test_if_cheaper_ordering过程中，改用字段f1的区分度来计算即可。