時計を壊せ

駆け出してからそこそこ経ったWebプログラマーの雑記

ORDER BY狙いのキーが何故速いか

どの最適化が効くんや…とググった。
以前も調べた気がしたが思いだせず、ひたすらググる羽目になったので、
反省してブログに残す。ふつーにmysqlのdocumentに書いてあった。


http://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html

If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. If ordering is done by using an index, this is very fast.

バージョン古いけど日本語のほうも同じ内容書いてある。http://dev.mysql.com/doc/refman/5.1/ja/limit-optimization.html


というわけで、LIMITを付けていてかつORDER BYにINDEXが使われる場合は、
row_countぶん発見したらソートfetchを中断して結果を返すので、
rowsが結構デカくなってもLIMITがバカでかいとかでない限りだいたい速いということっぽい。
this is very fast. と言い切るあたり、かっこいいとおもう。


元ネタ: http://togetter.com/li/564015http://www.slideshare.net/yoku0825/devsdba


追記: MySQL Performance blogに詳しく書いてある記事があった
http://www.mysqlperformanceblog.com/2006/09/01/order-by-limit-performance-optimization/


追記2: covering indexにならなくとも最適化は効くと思ってたので、検証してみます。分かったら追記します。
b+tree indexはsort済みなのでsortしなおす訳がなくて、たしかに「ソートを中断」より「fetchを中断」のほうが正しかったです。