數據庫優化SQL優化之SELECT優化 ——order by 優化

        在使用sql查詢數據庫的數據時，經常會使用到排序的操作，因此，如果對於排序的

數據，不能用到索引，將是一個很好時間的事情，數據庫的解決方法有兩個：1、選擇

完所有行後，數據較少，用內存來排序;2、數據較大，用硬盤文件排序，這將很耗時，

特別影響性能。

        而如果能運用好索引，則會少很多排序的消耗，因爲當使用排序時，只根據索引

去順序讀取，然後發送到客戶端。

1、當使用排序時，複合索引不需要額外排序的情形

       a、對於複合索引時，最前面的列在排序字段中

SELECT * FROM t1
  ORDER BY key_part1,key_part2,... 

       b、排序的字段不是複合索引的第一個，但where條件包含第一個且爲常量

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2;

       c、只使用到複合索引的第一個列

SELECT * FROM t1
  WHERE key_part1 > constant
  ORDER BY key_part1 ASC;

注：對於複合索引，如果要排序，能用到索引，必須用到複合索引的第一個字段纔可以

2、以下情形，用不到索引，用額外的排序

       a、使用不同的索引

SELECT * FROM t1 ORDER BY key1, key2;

       b、只使用到部分的複合索引，但不是複合索引的第一個列

SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;

       c、對複合索引，同時有升序和降序

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;

       d、對於要獲取的行的篩選條件和排序條件不一致時

SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

       e、對於排序的列上，還加有其他的函數處理，打亂了原來索引的順序

SELECT * FROM t1 ORDER BY ABS(key);
SELECT * FROM t1 ORDER BY -key;

       f、當jion了很多表時，order by後面的字段不是所有的列都來自第一個非

             常量表中的索引字段，（第一個非常量表爲在EXPLAIN中第一個不是

             type爲const的類型的表），因爲排序只能根據一個表的字段排序，不

             能跨表排序

       g、使用不同的group by 和order by語句，其實，當你使用group by 語句時

              他已經給你排序了。

              建議，當數據很大的時候，寫group by時，對數據的順序不關心時，加

              上一個order by null減少排序的操作

       h、如果使用的排序字段的前面的一部分，也不能用到排序索引，這種情況下

              經常會使用文件排序filesort,如有一個字段char(20),但只對前面的10個字節

               做了索引了，那麼直接排序時，將使用文件排序來達到正確排序

       i、使用hash索引時也無法排序使用

       j、當對一個索引列重命名後爲原來的名字，但後面友想以此來排序，也不能

            使用索引，如：

SELECT ABS(a) AS a FROM t1 ORDER BY a;

            原因是：order by 找的字段優先考慮重select的字段查找，然後查找表的字段

                            由於做了別的運算，導致索引已經無法使用了

             但改爲別的名字就可以用了，如：

SELECT ABS(a) AS b FROM t1 ORDER BY a;