一個案例完全弄懂如何正確使用 mysql inndb 聯合索引

摘要： 有一個業務是查詢最新審覈的5條數據 ```sql SELECT `id`, `title` FROM `th_content` WHERE `audit_time` < 1541984478 AND `status` = 'ONLINE' ORDER BY `audit_time` D.

原來連接 https://mengkang.net/1302.html

有一個業務是查詢最新審覈的5條數據

SELECT `id`, `title`
FROM `th_content`
WHERE `audit_time` < 1541984478
    AND `status` = 'ONLINE'
ORDER BY `audit_time` DESC, `id` DESC
LIMIT 5;

查看當時的監控狀況 cpu 使用率是超過了100%，show processlist看到不少相似的查詢都是處於create sort index的狀態。

查看該表的結構

CREATE TABLE `th_content` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(500) CHARACTER SET utf8 NOT NULL DEFAULT '' COMMENT '內容標題',
  `content` mediumtext CHARACTER SET utf8 NOT NULL COMMENT '正文內容',
  `audit_time` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '審覈時間',
  `last_edit_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最近編輯時間',
  `status` enum('CREATED','CHECKING','IGNORED','ONLINE','OFFLINE') CHARACTER SET utf8 NOT NULL DEFAULT 'CREATED' COMMENT '資訊狀態',
  PRIMARY KEY (`id`),
  KEY `idx_at_let` (`audit_time`,`last_edit_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

索引有一個audit_time在左邊的聯合索引，沒有關於status的索引。

分析上面的sql執行的邏輯：

• 從聯合索引裏找到全部小於該審覈時間的主鍵id（假如在該時間戳以前已經審覈了100萬條數據，則會在聯合索引裏取出對應的100萬條數據的主鍵 id）
• 對這100萬個 id 進行排序（爲的是在下面一步回表操做中優化 I/O 操做，由於不少捱得近的主鍵可能一次磁盤 I/O 就都取到了）
• 回表，查出100萬行記錄，而後逐個掃描，篩選出status='ONLINE'的行記錄
• 最後對查詢的結果進行排序（假若有50萬行都是ONLINE，則繼續對這50萬行進行排序）

最後由於數據量很大，雖然只取5行，可是按照咱們剛剛舉的極端例子，實際查詢了100萬行數據，並且最後還在內存中進行了50萬行數據庫的內存排序。

因此是很是低效的。

畫了一個示意圖，說明第一步的查詢過程，粉紅色部分表示最後須要回表查詢的數據行。
圖中我按照索引存儲規律來YY僞造填充了一些數據，若有不對請留言指出。但願經過這張圖你們可以看到聯合索引存儲的方式和索引查詢的方式

改進思路 1

範圍查找向來不太好使用好索引的，若是咱們增長一個audit_time, status的聯合索引，會有哪些改進呢？

ALTER TABLE `th_content` ADD INDEX `idx_audit_status` (`audit_time`, `status`);

mysql> explain select `id`, `title` from `th_content` where `audit_time` < 1541984478 and `status` = 'ONLINE' order by `audit_time` desc, `id` desc limit 5;
+----+-------------+------------+-------+------------------------------------------+------------------+---------+------+--------+-------------+
| id | select_type | table      | type  | possible_keys                            | key              | key_len | ref  | rows   | Extra       |
+----+-------------+------------+-------+------------------------------------------+------------------+---------+------+--------+-------------+
|  1 | SIMPLE      | th_content | range | idx_at_ft_pt_let,idx_audit_status        | idx_audit_status | 4       | NULL | 209754 | Using where |
+----+-------------+------------+-------+------------------------------------------+------------------+---------+------+--------+-------------+

細節：由於audit_time是一個範圍查找，因此第二列的索引用不上了，只能用到audit_time，因此key_len是4。而下面思路2中，仍是這兩個字段key_len則是5。

仍是分析下在添加了該索引以後的執行過程：

• 從聯合索引裏找到小於該審覈時間的audit_time最大的一行的聯合索引
• 而後依次往下找，由於< audit_time是一個範圍查找，而第二列索引的值是分散的。因此須要依次往前查找，匹配出知足條件（status='ONLINE'）的索引行，直到取到第5行爲止。
• 回表查詢須要的具體數據

在上面的示意圖中，粉紅色標識知足第一列索引要求的行，依次向前查詢，本個葉子節點上篩選到了3條記錄，而後須要繼續向左，到前一個葉子節點繼續查詢。直到找到5條知足記錄的行，最後回表。

改進之處

由於在索引裏面有status的值，因此在篩選知足status='ONLINE'行的時候，就不用回表查詢了。在回表的時候只有5行數據的查詢了，在iops上會大大減小。

該索引的弊端

若是idx_audit_status裏掃描5行都是status是ONLINE，那麼只需掃描5行；
若是idx_audit_status裏掃描前100萬行中，只有4行status是ONLINE，則須要掃描100萬零1行，才能獲得須要的5行記錄。索引須要掃描的行數不肯定。

改進思路 2

ALTER TABLE `th_content` DROP INDEX `idx_audit_status`;
ALTER TABLE `th_content` ADD INDEX `idx_status_audit` (`status`, `audit_time`);

這樣無論是排序仍是回表都毫無壓力啦。

原文連接