MySQL 選錯索引的原因？
阿新 • • 發佈：2020-05-21
MySQL 中，可以為某張表指定多個索引，但在語句具體執行時，選用哪個索引是由 MySQL 中執行器確定的。那麼執行器選擇索引的原則是什麼，以及會不會出現選錯索引的情況呢？
先看這樣一個例子：
建立表 Y，設定兩個**普通索引**, 建立一個儲存過程用於插入資料。
> MySQL: 5.7.27, 隔離級別: RR
```
CREATE TABLE `Y` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `a` (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB；
```
```
delimiter ;;
create procedure idata()
begin
declare i int;
set i=1;
while(i<=100000)do
insert into Y (`a`,`b`) values(i, i);
set i=i+1;
end while;
end;;
delimiter ;
call idata();
```
檢視如下事務：
| Session A | Session B |
| ------------------------------------------- | ------------------------------------------------------------ |
| start transaction with consistent snapshot; | |
| | delete from t; |
| | call idata(); |
| | explain select * from Y where a between 10000 and 20000; |
| | explain select * from Y force index(a) where a between 10000 and 20000; |
| commit; | |
如果單獨執行 Session B 中 `select * from Y where a between 10000 and 20000;`，毫無疑問會選擇 a 這個索引。
但如果安裝 Session A，Session B 的順序執行，發現索引的選擇如下：
可以發現，在 Session B 的場景下，執行器卻沒有選擇 a 所在的索引，而是選擇基於主鍵索引的全表掃描。
```
set long_query_time=0;
將慢查詢日誌開啟，並將闕值設為 0. 在記錄的日誌中，
可以發現 MySQL 並沒有選擇 a 所在的索引，同時花費了更長的時間。
```
這樣看，MySQL 的優化器不一定每次都能選擇合適的索引。想要理解出現該現象的原因，就要從優化器的選擇邏輯說起。
## 優化器
MySQL 中優化器的目的就是找到一個**最優的執行方案**，從而用最小的代價去執行語句。
優化器在選擇索引時，主要會考慮如下的因素：
* 掃描的行數：掃描的行數越少，就證明訪問磁碟資料的次數越少，消耗的 CPU 資源就越少。
* 有沒有涉及到臨時表
* 排序
### 關於掃描行數的確定
**計算索引的基數**
MySQL 在執行語句前，其實並不能準確的計算出掃描的行數，而是通過數學統計資訊來估算記錄數。這個統計資訊被稱為索引的“區分度”，在索引上不同的值越多，區分度就越高。在一個索引上不同值的個數，稱為“基數”。基數越大，索引的區分度越好。
這裡的 Cardinality 就是索引的基數，但基數並不是完全準確的。MySQL 是在獲取基數時，實際上是採用**取樣統計**的方式。
>