表結構：
sql：
SELECT vod_id FROM `ia_comment` where vod_id>0 and account_id=88;
SELECT vod_id FROM `ia_comment` where account_id=88;
結果：
[SQL]SELECT vod_id FROM `ia_comment` where vod_id>0 and account_id=88;
受影響的行: 0
時間: 0.323s
[SQL]
SELECT vod_id FROM `ia_comment` where account_id=88;
受影響的行: 0
時間: 0.152s
為什么第二條sql掃描的rows多效率反而更高
兩條sql得到的資料是一樣的
vod_id 全部大于0
uj5u.com熱心網友回復：
你用的是哪個版本 MySQL？uj5u.com熱心網友回復：
執行計劃，只是參考，不一定準確。好多時候，執行計劃好的，效率未必好。
uj5u.com熱心網友回復：
注意key_len，第一條SQL是4，說明只用到了聯合索引的第一個列vod_id，所以vod_id這個索引只用于vod_id>0的篩選，從索引讀取資料之后，還要進行account_id=88的判斷，慢就是慢在多出了另外判斷account_id=88；而第二條key_len是8，也就是說，where條件直接在索引上判斷。
所以第二潭訓快一點。
uj5u.com熱心網友回復：
為什么 possible_key 是空，key是非空，沒見過。extra內容不全，無法進一步判斷。uj5u.com熱心網友回復：
都是 Using where; Using index
uj5u.com熱心網友回復：
5.6版本
uj5u.com熱心網友回復：
注意key_len：第一條SQL是4，說明只用到了聯合索引的第一個列vod_id，所以vod_id這個索引只用于vod_id>0的篩選，從索引讀取資料之后，還要進行account_id=88的判斷。
第二條SQL是8，說明用的是組合索引。
rows：
當只用索引void_id時，vod_id>0 時，索引可能掃描25w+，當用組合做引時，可能掃描51W+，這個資料有時會是過期的不正確（有時需要table analysis下），用1列索引，2列索引時，有自己的策略，并不是說有50w 索引掃描就是50w，有可能是25W。
時間：
第一條、根據索引掃描后，每條都需要再次判斷是否=88。
第二條、根據索引可以直接定位到目標行。
這個把重點搞偏了，vod_id全部>0, 不應這樣寫where條件。account_id 為具體值，不應該在組合索引后。
目前這個索引基本也是費的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/45060.html
標籤：MySQL
上一篇：mysql字串GROUP_CONCAT拼接的時候，怎么指定分隔符為換行符呢？
下一篇：搜索引擎作業原理