眾所周知，InnoDB采用IOT（index organization table）即所謂的索引組織表，而葉子節(jié)點也就存放了所有的數(shù)據(jù)，這就意味著，數(shù)據(jù)總是按照某種順序存儲的。所以問題來了，如果是這樣一個語句，執(zhí)行起來應(yīng)該是怎么樣的呢？語句如下：

     列a上有一個索引，那么按照簡單的想法來講，如何掃描呢？很簡單，一條一條的掃描，這樣一來，其實做了一次索引全掃描，效率很差。這種掃描方式會掃描到很多很多的重復(fù)的索引，這樣說的話優(yōu)化的辦法也是很容易想到的：跳過重復(fù)的索引就可以了。于是網(wǎng)上能搜到這樣的一個優(yōu)化的辦法：

    從已經(jīng)搜索到的資料看，這樣的執(zhí)行計劃中的extra就從using index變成了using index for group-by。

    但是，但是，但是，好在我們現(xiàn)在已經(jīng)沒有使用5.1的版本了，大家基本上都是5.5以上了，這些現(xiàn)代版本，已經(jīng)實現(xiàn)了loose index scan：

     很好很好，就不需要再用這種奇技淫巧去優(yōu)化SQL了。

     文檔里關(guān)于group by這里寫的有點意思，說是最大眾化的辦法就是進(jìn)行全表掃描并且創(chuàng)建一個臨時表，這樣執(zhí)行計劃就會難看的要命了，肯定有ALL和using temporary table了。

5.0之后group by在特定條件下可能使用到loose index scan，

1

這兩條sql都只需一次index seek便可返回，源于索引的有序排序，優(yōu)化器意識到min/max位于最左/右塊，從而避免范圍掃描；
extra顯示Select tables optimized away ；
2

執(zhí)行計劃type 為range(extra顯示using where; using index)，即執(zhí)行索引范圍掃描，先讀取所有滿足log_machine約束的記錄，然后對其遍歷找出max value；
改進(jìn)