create sort index 案例分析

安利

原文：我的個人博客 https://mengkang.net/1302.html
工作了兩三年，技術停滯不前，迷茫沒有方向，安利一波我的直播 https://segmentfault.com/ls/1...

有一個業務是查詢最新審覈的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。
查看該表的索引有一個audit_time在左邊的聯合索引。

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

• 從聯合索引裏找到所有小於該審覈時間的主鍵id（因爲該sql查詢的是最新審覈的，假如之前已經審覈了100萬條數據，則會在聯合索引裏取出對應的100條數據的主鍵id）
• 回表，查出100萬行記錄，然後逐個掃描，篩選出status='ONLINE'的行記錄
• 最後對查詢的結果進行排序（假如有50萬行都是ONLINE，則繼續對這50萬行進行排序）

最後因爲數據量很大，雖然只取5行，但是按照我們剛剛舉的極端例子，實際查詢了100行數據，而且最後還在進行了50行的內存排序。

所以是非常低效的。

改進思路 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。

該索引的弊端

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

該索引的優勢

在索引裏面有status的值，就不用回表去查詢。

疑惑

我YY的兩個方案

1. 根據status,audit_time,id把索引數據進行排序，一次性排序，然後找出前5行；
2. 遍歷一遍通過status過濾出符合要求的行，然後再排序，找出前5行。

不管怎樣，這裏在回表的時候只有5行數據的查詢了，在iops上會大大減少。

改進思路 2

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

select count(*) from `th_content` where `audit_time` > '1541984478' and `status` = 'ONLINE';

只有7行，因爲業務屬性是取最新的5條，往往都是頭部數據。所以我們在使用idx_status_audit索引的時候，只需要掃描12行就能取到了所有的數據。

這樣不管是排序還是回表都毫無壓力。