SQL優化中，有一條放之四海而皆準的既定方針，那就是：永遠以小數據驅動大數據。其本質其實就是以小的數據樣本作為驅動查詢能夠優化查詢效率，在SQL中，涉及到不同表數據的連接、轉移、或者合併，這些操作必須得有個數據集作為“帶頭”大哥，即驅動數據，而這個驅動數據最好是數據量最小的那一個。 內大外小 在討論 ...
SQL優化中，有一條放之四海而皆準的既定方針，那就是：永遠以小數據驅動大數據。其本質其實就是以小的數據樣本作為驅動查詢能夠優化查詢效率，在SQL中，涉及到不同表數據的連接、轉移、或者合併，這些操作必須得有個數據集作為“帶頭”大哥，即驅動數據，而這個驅動數據最好是數據量最小的那一個。
內大外小
在討論資料庫之前，日常開發中，我們經常會遇到數據樣本數量不一致，但是需要進行檢索的情況，比如某人在地鐵的某節車廂里撿到N台Iphone，而車廂里正好有T個人，他應該怎麼去檢索雙樣本數據，從而找到失主？
for (int i = 0; i < N; i++)
for (int j = 0; j < T; j++)
find();
一般的說法是把迴圈次數少的迴圈放在外面，其實，這個問題的主要原因是CPU內部的指令執行機制。現在，基本上CPU內部都有分支指令預測，就是當執行（現在大多將這一階段提前到預取指令時執行）到轉移指令時，都會直接從分支目標緩存（BTB）中取出目標指令的地址，然後將要執行的指令提前預取到CPU的指令預取指令隊列中。這樣，顯然大大提高了效率。一個N次的一層迴圈在執行時，除了在第一次和最後一次會預測錯誤外，其他N-i次都會預取成功，避免了執行轉移指令時重新取出新指令造成的時間浪費。 所以，當有兩層迴圈，外層迴圈數為N，內層為T，N遠大於T，那麼最終造成的預測錯誤數為N*2+2，而如果外層數為T，內層數為N，預測錯誤數為T*2+2，顯然後者要節省更多時間，而且這個時間是很可觀的。N比T越大，這個時間差越明顯。
連表查詢
回到資料庫場景，連表查詢操作本質上其實就是掃描驅動表數據，根據條件，逐一去大表找數據，由小表作為驅動表，小表數據少，那麼去大表找數據時，能減少數據的找尋量。體現在底層上也就減少了網路的IO，記憶體，自然效率就高。
不同的連表方式也會有不同的驅動表，左連接中左邊為驅動表,右邊為被驅動表；右連接中右邊為驅動表,左邊為被驅動表；內連接中Mysql會選擇數據量比較小的表作為驅動表，大表作為被驅動表。我們也可以通過EXPLANIN關鍵字查看SQL語句的執行計劃，從而搞清楚一次連表查詢中的驅動表到底是那一張。
底層原理
連表查詢操作時，資料庫會從頭到尾掃描驅動表，複雜度為O(n)，也就是說有N條就要查N次，隨後再逐一去其它關聯表查詢數據，眾所周知，由於Mysql採用B+tree方式進行存放數據，關於B+tree，請移步：霜皮剝落紫龍鱗，下里巴人再談資料庫SQL優化，索引(一級/二級/聚簇/非聚簇)原理，因此查詢時間複雜度為O(logn)，總時間複雜度即為O(n)*O(logn)，說白了就是驅動數據集有多少條數據，就得在B+tree中查詢O(logn)次。
假設表n數據小於表m，則連表查詢操作時，O(n)*O(logm) 小於 O(m)*O(logn)，因此小數據集作為驅動數據相對就比較有效率。
子查詢
外小內大原則也同樣適用於子查詢，當子表的數據集較小時，使用In操作，效率較高：
SELECT * FROM A WHERE ID IN (SELECT ID FROM B)
這裡B表的數據量小於A表數據，很明顯B表作為查詢篩選的驅動表。
反之，當B表數據量大於外側的數據表A:
SELECT * FROM A WHERE EXISTS (SELECT 1 FROM B WHERE B.ID = A.ID)
此時使用EXISTS的效率更高，因為EXISTS是將主查詢的數據放到子查詢中做條件驗證，根據驗證結果（TRUE或者FALSE）來決定主查詢的數據結果是否能夠得以保留。
結語
迴圈嵌套優化原則的外小內大，資料庫SQL優化原則的以小博大，一脈相承，同出一轍，大道至簡，殊途同歸。
