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

2024-07-24 12:46:15

字体：大中小

来源：转载

供稿：网友

问题

用户工单疑问：相同的语句，只是最后的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 67id: 1select_type: SIMPLEtable: atype: rangepossible_keys: A,B,Ckey: Bkey_len: 387ref: NULLrows: 2555192Extra: Using where; Using temporary; Using filesort1 row in set (0.00 sec)LIMIT 68id: 1select_type: SIMPLEtable: atype: refpossible_keys: A,B,Ckey: Akey_len: 3ref: constrows: 67586Extra: Using where; Using temporary; Using filesort1 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/Gid: 1select_type: SIMPLEtable: atype: refpossible_keys:Akey: Akey_len: 3ref: constrows: 67586Extra: Using where; Using temporary; Using filesort1 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的优化器执行期间需要依赖于表的统计信息，而统计信息是估算值，因此有可能导致得到的执行计划非最优。

上一篇：在MySQL中使用GTIDs复制协议和中断协议的教程

下一篇：详细介绍基于MySQL的搜索引擎MySQL-Fullltext