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優化原則的以小博大，一脈相承，同出一轍，大道至簡，殊途同歸，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/540691.html
標籤：其他