SQL優化之SQL 進階技巧（下）

上文( SQL優化之SQL 進階技巧（上） )咱們簡述了 SQL 的一些進階技巧，一些朋友以爲不過癮，咱們繼續來下篇，再送你 10 個技巧

1、 使用延遲查詢優化 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 不是什麼大的開銷，因此這樣能夠顯著提高性能

2、 利用 LIMIT 1 取得惟一行

數據庫引擎只要發現知足條件的一行數據則當即中止掃描，，這種狀況適用於只需查找一條知足條件的數據的狀況

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

假設存在這樣順序的一個聯合索引「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，致使沒法命中索引， 另外若是沒法保證查詢條件裏列的順序與索引一致，能夠考慮將聯合索引 拆分爲多個索引。

4、使用 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%';

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

5、 簡單字符串表達式

模型字符串可使用 _ 時， 儘量避免使用 %, 假設某一列上爲 char(5)

不推薦

SELECT 
    first_name, 
    last_name,
    homeroom_nbr
  FROM Students
 WHERE homeroom_nbr LIKE 'A-1%';

推薦

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

6、儘可能使用自增 id 做爲主鍵

好比如今有一個用戶表，有人說身份證是惟一的，也能夠用做主鍵，理論上確實能夠，不過用身份證做主鍵的話，一是佔用空間相對於自增主鍵大了不少，二是很容易引發頻繁的頁分裂，形成性能問題（什麼是頁分裂，請參考這篇文章）

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

7、如何優化 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(*) 仍是很慢!

8、避免使用 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

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

業務團隊曾經出現相似如下的慢 SQL 查詢

SELECT *
  FROM  SomeTable
 WHERE `status` = 0
   AND `gmt_create` > 1490025600
   AND `gmt_create` < 1490630400
   AND `id` > 0
   AND `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 搜索引擎來查找更合適，有機會到時出一篇文章說說。

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

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

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

11、 批量插入，速度更快

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

推薦用

-- 批量插入
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 的事務讓日誌減小了，下降日誌刷盤的數據量和頻率，從而提升了效率

12、 慢日誌 SQL 定位

前面咱們屢次說了 SQL 的慢查詢，那麼該怎麼定位這些慢查詢 SQL 呢，主要用到了如下幾個參數

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

總結

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

相關文章

SQL優化之SQL 進階技巧（上）

SQL優化之SELECT COUNT(*)