上文我們簡述了 SQL 的一些進階技巧，一些朋友覺得不過癮，我們繼續來下篇，再送你 10 個技巧

一、 使用延遲查詢優化 limit [offset], [rows]

經常出現類似以下的 SQL 語句:

SELECT?*?FROM?film?LIMIT?100000,?10

offset 特別大!

這是我司出現很多慢 SQL 的主要原因之一，尤其是在跑任務需要分頁執行時，經常跑著跑著 offset 就跑到幾十萬了，導致任務越跑越慢。

LIMIT 能很好地解決分頁問題，但如果 offset 過大的話，會造成嚴重的性能問題，原因主要是因為 MySQL 每次會把一整行都掃描出來，掃描 offset 遍，找到 offset 之后會拋棄 offset 之前的數據，再從 offset 開始讀取 10 條數據，顯然，這樣的讀取方式問題。

可以通過延遲查詢的方式來優化

假設有以下 SQL,有組合索引（sex, rating）

SELECT?<cols>?FROM?profiles?where?sex='M'?order?by?rating?limit?100000,?10;

則上述寫法可以改成如下寫法

SELECT?<cols>?FROM?profiles? inner?join (SELECT?id?form?FROM?profiles?where?x.sex='M'?order?by?rating?limit?100000,?10) as?x?using(id);

這里利用了覆蓋索引的特性，先從覆蓋索引中獲取 100010 個 id，再丟充掉前 100000 條 id，保留最后 10 個 id 即可，丟掉 100000 條 id 不是什么大的開銷，所以這樣可以顯著提升性能

二、 利用 LIMIT 1 取得唯一行

數據庫引擎只要發現滿足條件的一行數據則立即停止掃描，，這種情況適用于只需查找一條滿足條件的數據的情況

三、 注意組合索引，要符合最左匹配原則才能生效

假設存在這樣順序的一個聯合索引“col_1, col_2, col_3”。這時，指定條件的順序就很重要。

○?SELECT?*?FROM?SomeTable?WHERE?col_1?=?10?AND?col_2?=?100?AND?col_3?=?500; ○?SELECT?*?FROM?SomeTable?WHERE?col_1?=?10?AND?col_2?=?100?; ×?SELECT?*?FROM?SomeTable?WHERE?col_2?=?100?AND?col_3?=?500?;

前面兩條會命中索引，第三條由于沒有先匹配 col_1，導致無法命中索引， 另外如果無法保證查詢條件里列的順序與索引一致，可以考慮將聯合索引 拆分為多個索引。

四、使用 LIKE 謂詞時，只有前方一致的匹配才能用到索引（最左匹配原則）

×?SELECT?*?FROM?SomeTable?WHERE?col_1?LIKE?'%a'; ×?SELECT?*?FROM?SomeTable?WHERE?col_1?LIKE?'%a%'; ○?SELECT?*?FROM?SomeTable?WHERE?col_1?LIKE?'a%';

上例中，只有第三條會命中索引，前面兩條進行后方一致或中間一致的匹配無法命中索引

五、 簡單字符串表達式

模型字符串可以使用 _ 時， 盡可能避免使用 %, 假設某一列上為 char(5)

不推薦

SELECT?first_name,?last_name,homeroom_nbrFROM?StudentsWHERE?homeroom_nbr?LIKE?'A-1%';

推薦

SELECT?first_name,?last_name homeroom_nbrFROM?StudentsWHERE?homeroom_nbr?LIKE?'A-1__';?--模式字符串中包含了兩個下劃線

六、盡量使用自增 id 作為主鍵

比如現在有一個用戶表，有人說身份證是唯一的，也可以用作主鍵，理論上確實可以，不過用身份證作主鍵的話，一是占用空間相對于自增主鍵大了很多，二是很容易引起頻繁的頁分裂，造成性能問題（什么是頁分裂，請參考這篇文章）

主鍵選擇的幾個原則：自增，盡量小，不要對主鍵進行修改

七、如何優化 count(*)

使用以下 sql 會導致慢查詢

SELECT?COUNT(*)?FROM?SomeTable SELECT?COUNT(1)?FROM?SomeTable

原因是會造成全表掃描，有人說?COUNT(*)?不是會利用主鍵索引去查找嗎，怎么還會慢，這就要談到 MySQL 中的聚簇索引和非聚簇索引了，聚簇索引葉子節點上存有主鍵值+整行數據，非聚簇索葉子節點上則存有輔助索引的列值 + 主鍵值，如下

所以就算對 COUNT(*) 使用主鍵查找，由于每次取出主鍵索引的葉子節點時，取的是一整行的數據，效率必然不高，但是非聚簇索引葉子節點只存儲了「列值 + 主鍵值」,這也啟發我們可以用非聚簇索引來優化，假設表有一列叫 status, 為其加上索引后，可以用以下語句優化:

SELECT?COUNT(status)?FROM?SomeTable

有人曾經測過（見文末參考鏈接），假設有 100 萬行數據，使用聚簇索引來查找行數的，比使用 COUNT(*) 查找速度快 10 幾倍。不過需要注意的是通過這種方式無法計算出 ?status 值為 null 的那些行

如果主鍵是連續的，可以利用 MAX(id) 來查找，MAX 也利用到了索引，只需要定位到最大 id 即可，性能極好，如下，秒現結果

SELECT?MAX(id)?FROM?SomeTable

說句題句話，有人說用 MyISAM 引擎調用 COUNT(*) 非常快，那是因為它提前把行數存在磁盤中了，直接拿，當然很快，不過如果有 WHERE 的限制,用 COUNT(*) 還是很慢!

八、避免使用 SELECT * ，盡量利用覆蓋索引來優化性能

SELECT *?會提取出一整行的數據，如果查詢條件中用的是組合索引進行查找，還會導致回表（先根據組合索引找到葉子節點，再根據葉子節點上的主鍵回表查詢一整行），降低性能，而如果我們所要的數據就在組合索引里，只需讀取組合索引列，這樣網絡帶寬將大大減少,假設有組合索引列 (col_1, col_2)

推薦用

SELECT?col_1,?col_2?FROM?SomeTable?WHERE?col_1?=?xxx?AND?col_2?=?xxx

不推薦用

SELECT?*FROM?SomeTable?WHERE?col_1?=?xxx?AND??col_2?=?xxx

九、 如有必要，使用 force index() 強制走某個索引

業務團隊曾經出現類似以下的慢 SQL 查詢

SELECT?*FROM??SomeTableWHERE?`status`?=?0AND?`gmt_create`?>?1490025600AND?`gmt_create`?<?1490630400AND?`id`?>?0AND?`post_id`?IN?('67778',?'67811',?'67833',?'67834',?'67839',?'67852',?'67861',?'67868',?'67870',?'67878',?'67909',?'67948',?'67951',?'67963',?'67977',?'67983',?'67985',?'67991',?'68032',?'68038'/*...?omitted?480?items?...*/) order?by?id?asc?limit?200;

post_id 也加了索引，理論上走 post_id 索引會很快查詢出來，但實際通過 EXPLAIN 發現走的卻是 id 的索引（這里隱含了一個常見考點，在多個索引的情況下, MySQL 會如何選擇索引），而 id > 0 這個查詢條件沒啥用，直接導致了全表掃描， 所以在有多個索引的情況下一定要慎用，可以使用 force index 來強制走某個索引，以這個例子為例，可以強制走 post_id 索引，效果立桿見影。

這種由于表中有多個索引導致 MySQL 誤選索引造成慢查詢的情況在業務中也是非常常見，一方面是表索引太多，另一方面也是由于 SQL 語句本身太過復雜導致， 針對本例這種復雜的 SQL 查詢，其實用 ElasticSearch 搜索引擎來查找更合適，有機會到時出一篇文章說說。

十、 使用 EXPLAIN 來查看 SQL 執行計劃

上個點說了，可以使用 EXPLAIN 來分析 SQL 的執行情況，如怎么發現上文中的最左匹配原則不生效呢，執行 「EXPLAIN + SQL 語句」可以發現 key 為 None ,說明確實沒有命中索引

我司在提供 SQL 查詢的同時，也貼心地加了一個 EXPLAIN 功能及 sql 的優化建議，建議各大公司效仿 ^_^,如圖示

十一、 批量插入，速度更快

當需要插入數據時，批量插入比逐條插入性能更高

推薦用

--?批量插入 INSERT?INTO?TABLE?(id,?user_id,?title)?VALUES?(1,?2,?'a'),(2,3,'b');

不推薦用

INSERT?INTO?TABLE?(id,?user_id,?title)?VALUES?(1,?2,?'a'); INSERT?INTO?TABLE?(id,?user_id,?title)?VALUES?(2,3,'b');

批量插入 SQL 執行效率高的主要原因是合并后日志量 MySQL 的 binlog 和 innodb 的事務讓日志減少了，降低日志刷盤的數據量和頻率，從而提高了效率

十二、 慢日志 SQL 定位

前面我們多次說了 SQL 的慢查詢，那么該怎么定位這些慢查詢 SQL 呢，主要用到了以下幾個參數

這幾個參數一定要配好，再根據每條慢查詢對癥下藥，像我司每天都會把這些慢查詢提取出來通過郵件給形式發送給各個業務團隊，以幫忙定位解決

總結

業務生產中可能還有很多 CASE 導致了慢查詢，其實細細品一下，都會發現這些都和 MySQL 索引的底層數據 B+ 樹 有莫大的關系，強烈建議大家看一下我的另一篇介紹 B+ 樹的文章，好評如潮！相信大家看了之后，以上出現的問題會有一個更深層次的理解，掌握底層，以不變應萬變!

?

?

巨人的肩膀

https://plu.one/mysql/2018/10/18/mysql-deffered-join/

https://blog.csdn.net/u012674931/article/details/52711137

總結

以上是生活随笔為你收集整理的SQL 进阶技巧（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。