MySQL——優化嵌套查詢和分頁查詢

優化嵌套查詢

嵌套查詢（子查詢）能夠使用SELECT語句來建立一個單列的查詢結果，而後把這個結果做爲過濾條件用在另外一個查詢中。嵌套查詢寫起來簡單，也容易理解。可是，有時候能夠被更有效率的鏈接（JOIN)替代。

如今假如要找出歷來沒有在網站中消費的客戶，也就是查詢在客戶customer表中可是不在支付payment表中的客戶信息。

嵌套查詢：

explain select * from customer where customer_id not in (select customer_id from payment);

鏈接改寫：

explain select * from customer a left join payment b on a.customer_id = b.customer_id where b.customer_id is null;

畫外音：鏈接查詢效率更高的緣由，是由於MySQL不須要在內存中建立臨時表來完成這個邏輯上須要兩個步驟的查詢工做；而且Not exists表示MYSQL優化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標準的行， 就再也不搜索了。

優化分頁查詢

在MySQL中作分頁查詢，MySQL 並非跳過 offset 行，而是取 offset+N 行，而後返回放棄前 offset 行，返回 N 行，那當 offset 特別大的時候，效率就很是的低下。例如「limit 1000,20」，此時MySQL排序出前1020條數據後僅僅須要第1001到1020條記錄，前1000條數據都會被拋棄，查詢和排序的代價很是高。因而可知MySQL的分頁處理並非十分完美，須要咱們在分頁SQL上作一些優化，要麼控制返回的總頁數，要麼對超過特定閾值的頁數進行 SQL 改寫。

畫外音：控制返回的總頁數並非那麼靠譜，畢竟每頁的數據量也不能過大，數據多起來以後，控制返回的總頁數就變的不現實了。因此仍是要對超過特定閾值的頁數進行 SQL 改寫。

如今假設要對電影表film排序後取某一頁數據

explain select * from film order by title limit 50,5;

能夠看到優化器實際上作了全表掃描，處理效率不高。

第一種優化思路

在索引上完成排序分頁的操做，最後根據主鍵關聯回表查詢所須要的其餘列內容。

畫外音：此處涉及到了SQL優化的兩個重要概念，索引覆蓋和回表，我在前面的文章中詳細介紹過這兩個概念。經過索引覆蓋在索引上完成掃描和排序（索引有序），最後經過主鍵（InnoDB引擎索引會經過主鍵回表）回表查詢，最大限度減小回表查詢的I/O次數。

explain select * from film a inner join (select film_id from film order by title limit 50,5)b on a.film_id = b.film_id;

第二種優化思路

把LIMIT查詢轉換成某個位置的查詢，減小分頁翻頁的壓力。

假設如今每頁10條數據，要取第42頁的數據。

explain select * from film order by title limit 410,10;

如今須要多傳一個參數，就是上一頁（第41頁）的最後一條數據的主題title，

SQL能夠改寫爲：

explain select * from film where title>'HOLES BRANNIGAN' order by title limit 10;

這樣就把LIMIT m,n 轉換成了LIMIT n的查詢，可是這種方案只適合在不會出現重複值的特定環境，不然分頁結果可能會丟失數據。

總結

對於嵌套查詢和分頁查詢的優化，歸根結底就是遵循SQL優化原則之一——減小回表查詢的I/O次數。對於分頁查詢優化，更建議使用第一種優化方案，性能更好，穩定性更高。

參考

《深刻淺出MySQL》

做者：CoderFocus

微信公衆號：

聲明：本文爲博主學習感悟總結，水平有限，若是不當，歡迎指正。若是您認爲還不錯，不妨點擊一下下方的【推薦】按鈕，謝謝支持。轉載與引用請註明做者及出處。