問題

用戶工單疑問：相同的語句，只是最后的limit行數(shù)不同。奇怪的是，limit 10 的性能比limit 100的語句還慢約10倍。

隱藏用戶表信息，語句及結(jié)果如下

執(zhí)行時(shí)間3 min 3.65 sec

執(zhí)行時(shí)間1.24Sec.

性能差距非常大！

分析
MySQL Tips：追查語句執(zhí)行時(shí)最常用的方法，是通過explain來看語句的執(zhí)行計(jì)劃。 ?

更有沖擊性的效果是通過縮小范圍后，在這個(gè)數(shù)據(jù)下，limit 67和limit 68的執(zhí)行計(jì)劃相差很大。

兩個(gè)執(zhí)行計(jì)劃：

可以看到，兩個(gè)語句的執(zhí)行計(jì)劃不同：使用的索引不同。

MySQL Tips：explain的結(jié)果中，key表示最終使用的索引，rows表示使用這個(gè)索引需要掃描的行數(shù)，這是個(gè)估計(jì)值。

表中 索引A定義為 (f3, f4, f1, f2, f5); 索引B定義為(f1, f2, f3);

一個(gè)確認(rèn)

雖然rows是估計(jì)值，但是指導(dǎo)索引使用的依據(jù)。既然limit 68能達(dá)到rows 67586,說明在第一個(gè)語句優(yōu)化器可選結(jié)果中，也應(yīng)該有此值，為什么不會(huì)選擇索引A？
先確認(rèn)一下我們上面的這個(gè)結(jié)論。

MySQL Tips：MySQL語法中能夠用force index 來強(qiáng)行要求優(yōu)化器使用某一個(gè)索引。

順便說明，由于我們指定了force index，因此優(yōu)化器不會(huì)考慮其他索引，possible_keys里只會(huì)顯示A。我們關(guān)注的是rows:67586。這說明在limit 67語句里，使用索引A也能夠減少行掃描。

MySQL Tips：MySQL優(yōu)化器會(huì)對(duì)possiable_key中的每個(gè)可能索引都計(jì)算查詢代價(jià)，選擇最小代價(jià)的查詢計(jì)劃。

至此我們大概可以猜測，這個(gè)應(yīng)該是MySQL實(shí)現(xiàn)上的bug：沒有選擇合適的索引，導(dǎo)致使用了明顯錯(cuò)誤的執(zhí)行計(jì)劃。

MySQL Tips：MySQL的優(yōu)化器執(zhí)行期間需要依賴于表的統(tǒng)計(jì)信息，而統(tǒng)計(jì)信息是估算值，因此有可能導(dǎo)致得到的執(zhí)行計(jì)劃非最優(yōu)。