共計 1518 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章主要介紹“MySQL 優化語句執行的方法有哪些”，在日常操作中，相信很多人在 MySQL 優化語句執行的方法有哪些問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MySQL 優化語句執行的方法有哪些”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

like 前導符優化

like 模糊查詢形如 %AAA% 和 %AAA 將不會使用索引，但是業務上不可避免可能又需要使用到這種形式。

通常的方法有兩種：

優化方案一：使用覆蓋索引，即查詢出的列只是用索引就可以獲取，而無須查詢表記錄，這樣也走了索引;

優化方案二：使用 locate 函數或者 position 函數代替 like 查詢：如 table.field like %AAA% 可以改為 locate(AAA ,  table.field) 0 或 POSITION(AAA IN table.field) 0

in 和 exist

如果查詢的兩個表大小相當，那么用 in 和 exists 差別不大。如果兩個表中一個較小，一個是大表，則子查詢表大的用 exists，子查詢表小的用 in：  例如：表 A(小表)，表 B(大表)

示例一：

示例二：

not in 和 not exist

如果查詢語句使用了 not in 那么內外表都進行全表掃描，沒有用到索引; 而 not exist 的子查詢依然能用到表上的索引。所以無論哪個表大，用 not  exists 都比 not in 要快!

子查詢優化

MySQL 5.6   之前的版本對子查詢處理：不會將查詢的結果集計算出來用作與其他表做 join,outer 表每掃描一條數據，子查詢都會被重新執行一遍。

MySQL 5.6 對子查詢的處理：將子查詢的結果集 cache   到臨時表里，臨時表索引主要用來移除重復記錄，并且隨后也可能用于做 join 查詢，這種技術在 5.6   中叫做物化的子查詢，物化子查詢可以看到 select_type 字段為 subquery，而在 5.5 里為 DEPENDENT SUBQUERY。

子查詢一般都可以改成表的關聯查詢，子查詢會有臨時表的創建、銷毀，效率低下。

straight_join

mysql hint：

Mysql 優化器在處理多表的關聯的時候，很有可能會選擇錯誤的驅動表進行關聯，導致了關聯次數的增加，從而使得 sql 語句執行變得非常的緩慢。

這個時候需要有經驗的 DBA 進行判斷，選擇正確的驅動表，這個時候 straightjoin   就起了作用了，下面我們來看一看使用 straight_join 進行優化的案例：

嘗試采用 user 表做驅動表，使用 straight_join 強制連接順序：

高效分頁

傳統分頁：

select * from table limit 10000,10

limit 原理：

Limit 10000,10

偏移量越大則越慢

推薦分頁：

復雜關聯 SQL 的優化

首先查詢返回的結果集，通常查詢返回的結果集很少，是有優化的空間的。

通過查看執行計劃，查看優化器選擇的驅動表，從執行計劃的 rows 可以大致反應出問題的所在。

搞清各表的關聯關系，查看關聯字段是否有合適的索引。

使用 straight_join 關鍵詞來強制調整驅動表的選擇，對優化的想法進行驗證。

如果條件允許，對復雜的 SQL 進行拆分。盡可能越簡單越好。

force index

有時優化器可能由于統計信息不準確等原因，沒有選擇 *** 的執行計劃，可以人為改變 mysql 的執行計劃，例如：

count 的優化

按照效率排序的話，count(字段)

到此，關于“MySQL 優化語句執行的方法有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！