MySQL 超大數據量的一些優化

1．IN 就相當於 OR，如果使用一個 IN 查詢聚合索引第一列，那麼整個聚合索引就只相當於第一個鍵索引，聚合將失效。

2．避免相關子查詢

　　一個列的標籤同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當儘量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉儘可能多的行。

3．使用臨時表加速查詢

　　把表的一個子集進行排序並創建臨時表，有時能加速查詢。有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：

　　SELECT cust.name，rcvbles.balance，……other columns

　　FROM cust，rcvbles

　　WHERE cust.customer_id = rcvlbes.customer_id

　　AND rcvblls.balance>0

　　AND cust.postcode>“98000”

　　ORDER BY cust.name

　　如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：

　　SELECT cust.name，rcvbles.balance，……other columns

　　FROM cust，rcvbles

　　WHERE cust.customer_id = rcvlbes.customer_id

　　AND rcvblls.balance>0

　　ORDER BY cust.name

　　INTO TEMP cust_with_balance

　　然後以下面的方式在臨時表中查詢：

　　SELECT ＊ FROM cust_with_balance

　　WHERE postcode>“98000”

　　臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁盤I/O，所以查詢工作量可以得到大幅減少。
　　注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。

4．消除對大型錶行數據的順序存取

　　在嵌套查詢中，對錶的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在“學號”這個連接字段上建立索引。

　　還可以使用並集來避免順序存取。儘管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：

　　SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

　　雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因爲這個語句要檢索的是分離的行的集合，所以應該改爲如下語句：

　　SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001

　　UNION

　　SELECT ＊ FROM orders WHERE order_num=1008

　　這樣就能利用索引路徑處理查詢。

5、union並不絕對比or的執行效率高

我們前面已經談到了在where子句中使用or會引起全表掃描,一般的,我所見過的資料都是推薦這裏用union來代替or。事實證明,這種說法對於大部分都是適用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=‘2004-9-16‘ or gid>9990000

用時：68秒。掃描計數 1,邏輯讀 404008 次,物理讀 283 次,預讀 392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=‘2004-9-16‘ 

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

用時：9秒。掃描計數 8,邏輯讀 67489 次,物理讀 216 次,預讀 7499 次。

看來,用union在通常情況下比用or的效率要高的多。

但經過試驗,筆者發現如果or兩邊的查詢列是一樣的話,那麼用union則反倒和用or的執行速度差很多,雖然這裏union掃描的是索引,而or掃描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=‘2004-9-16‘ or fariqi=‘2004-2-5‘

用時：6423毫秒。掃描計數 2,邏輯讀 14726 次,物理讀 1 次,預讀 7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=‘2004-9-16‘ 

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where  fariqi=‘2004-2-5‘

用時：11640毫秒。掃描計數 8,邏輯讀 14806 次,物理讀 108 次,預讀 1144 次。

6、order by按聚集索引列排序效率最高

我們來看：(gid是主鍵,fariqi是聚合索引列）

select top 10000 gid,fariqi,reader,title from tgongwen

用時：196 毫秒。 掃描計數 1,邏輯讀 289 次,物理讀 1 次,預讀 1527 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc

用時：4720毫秒。 掃描計數 1,邏輯讀 41956 次,物理讀 0 次,預讀 1287 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用時：4736毫秒。 掃描計數 1,邏輯讀 55350 次,物理讀 10 次,預讀 775 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc

用時：173毫秒。 掃描計數 1,邏輯讀 290 次,物理讀 0 次,預讀 0 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc

用時：156毫秒。 掃描計數 1,邏輯讀 289 次,物理讀 0 次,預讀 0 次。

從以上我們可以看出,不排序的速度以及邏輯讀次數都是和“order by 聚集索引列” 的速度是相當的,但這些都比“order by 非聚集索引列”的查詢速度是快得多的。

同時,按照某個字段進行排序的時候,無論是正序還是倒序,速度是基本相當的。