今天遇到了乙個問題，生存環境有乙個表查詢耗時超過3s，導致前端超時。大概有三百萬條資料，其中用到了order by，當時排查就是排序（filesort）導致查詢時間過長，所以想到就是給order by的字段加乙個索引，於是我就在測試環境測試（測試環境資料很少100多條的樣子），但是發現了乙個很奇怪的問題，查詢的時候並沒有用到索引。
如圖所示，用的還是filesort，百思不得其解。。。反反覆覆查資料，看到一段很關鍵的話：innodb引擎對於查詢的優化以及索引的使用，引擎根據演算法得出如果全表查詢比索引更快時，將會忽略索引的使用。但是可以通過 force index(索引名稱)強制使用索引
select * from ***_*** force index(index_name) where。忽然間恍然大悟，我這測試環境就幾百條資料還用個屁的索引啊，當然全表查快啊，於是果斷從生產環境導了乙份資料到測試環境，再次查詢發現秒查，explain 後果然已經用上了索引，如下。然後我把order by的索引去掉了，發現了查詢了7秒。。。所以說這是乙個重大的失誤，對於有可能暴漲的資料表，order by的字段記得要加索引，時刻謹記！
對於order by子句
order by子句指定排序順序 select username from user order by username 依據username的字母順序對於查詢出來的username進行排序，預設是公升序 a z 也可以進行降序排序，必須指定desc關鍵字 在上面的sql語句變為 select us...
MySQL如何優化ORDER BY
某些情況中，mysql可以使用乙個索引來滿足order by子句，而不需要額外的排序。即使order by不確切匹配索引，只要where子句中的所有未使用的索引部分和所有額外的order by 列為常數，就可以使用索引。下面的查詢使用索引來解決order by部分 某些情況中，mysql可以使用乙個...
MySQL 優化 ORDER BY 優化
本文翻譯自mysql 官網 order by optimization，mysql 版本 5.7。這一部分描述了mysql何時會使用索引來滿足order by子句，filesort 操作會在索引不能生效的時候被用到，以及優化器對order by的執行計畫資訊。order by後面有沒有跟著limit...