MySQL SELECT中LIMIT時EXPLAIN估算ROWS不準確的替代方法

在MySQL性能調試中，常常使用EXPLAIN解釋MySQL執行計劃，從而用來估算性能耗時。其中，rows用來表示在SQL執行過程中會被掃描的行數，該數值越大，意味着需要掃描的行數，相應的耗時更長。但是需要注意的是EXPLAIN中輸出的rows只是一個估算值，不能完全對其百分之百相信，如EXPLAIN中對LIMITS的支持就比較有限。可以參考文章《MySQL EXPLAIN limits and errors》。

1. 創建一個測試用表TEMP作爲實現

CREATE TABLE TEMP (

        TYPE varchar(64) NOT NULL,

        CREATED_AT timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6)

);

2. 創建相應Index

CREATE INDEX IDX_TEMP_type_createdAt on TEMP(TYPE, CREATED_AT);

3. 隨機插入數據

隨機插入10000條數據，其中TYPE字段隨機插入['A', 'B', 'C', 'D', 'E']五個值中的任意一個

4. 使用EXPLAIN進行rows解釋

EXPLAIN SELECT * FROM TEMP WHERE TYPE = 'A' ORDER BY CREATED_AT DESC LIMIT 10;

結果：

select_type typekey key_len ref rowsfiltered Extra
SIMPLE ref IDX_TEMP_type_createdAt258 const2017 100Using where; Using index

可以看到rows是2017，有2017行被掃描

5. 使用SHOW STATUS嘗試解釋

a)首先執行SQL，注意去掉EXPLAIN

SELECT * FROM TEMP WHERE TYPE = 'A' ORDER BY CREATED_AT DESC LIMIT 10;

b)執行SHOW STATUS查看當前狀態

SHOW SESSION STATUS LIKE "Handler%"

結果：

Variable_nameValue
Handler_commit 1
Handler_delete 0
Handler_discover 0
Handler_external_lock 2
Handler_mrr_init 0
Handler_prepare 0
Handler_read_first 1
Handler_read_key 2
Handler_read_last 0
Handler_read_next 0
Handler_read_prev9
Handler_read_rnd 0
Handler_read_rnd_next 3
Handler_rollback 0
Handler_savepoint 0
Handler_savepoint_rollback 0
Handler_update 0
Handler_write 0

可以看到還剩9條數據沒有讀，這纔是實際準確的值