一 explain
? 1 掃描行數(shù)根據(jù)的是表的統(tǒng)計元數(shù)據(jù)
? 2 索引的元數(shù)據(jù)具體指的就是show index from查到的索引的區(qū)分度,索引的區(qū)分度越高越好
? 3 表的元數(shù)據(jù)是定期收集,所以可能不準(zhǔn)確
? 4 如果感覺explain不準(zhǔn)確,可以用analyze table t命令重新收集
? 5 元數(shù)據(jù)不準(zhǔn)確的場景大多出現(xiàn)在大量刪除數(shù)據(jù)和插入數(shù)據(jù)場景,針對大表尤其如此
二 元數(shù)據(jù)收集
? 參數(shù) innodb_stats_persistent=ON 默認(rèn)會持久化到內(nèi)存 默認(rèn)打開
? 參數(shù) innodb_stats_auto_recalc 這個參數(shù)控制著在表中行的數(shù)量改變超過10%的時候，是否重新收集統(tǒng)計信息 這個收集的動作是異步的，在執(zhí)行完大的dml后，可能會過一段時間才重新收集統(tǒng)計信息 默認(rèn)打開
? 參數(shù) innodb_stats_persistent_sample_pages 采樣使用的頁數(shù) 默認(rèn)20 1 調(diào)大可能使analyze命令緩慢,加重負(fù)擔(dān) 2調(diào)小可能使大量的執(zhí)行計劃產(chǎn)生誤區(qū),并不建議調(diào)整此值
三 mysql優(yōu)化器選擇錯誤索引的方法
? 1 采用force index強(qiáng)制走某項索引,但是這可能導(dǎo)致一個問題,以后系統(tǒng)遷移或者索引名變更會導(dǎo)致問題
? 2 改寫sql語句,讓mysql優(yōu)化器進(jìn)行再次判斷,選擇正確的索引
? 3 直接刪除索引本身,讓mysql優(yōu)化器無法選擇該索引
四 總結(jié)
?1 如果出現(xiàn)mysql執(zhí)行計劃不準(zhǔn)確的情況下,可以采用上述方式進(jìn)行處理,一般情況下,出現(xiàn)索引判斷失誤的情況比較少

五 明顯失效的幾個場景

? ? 1 當(dāng)range出現(xiàn)? row掃描為1 ROW時候? ?

? ? 2? 掃描的行數(shù)遠(yuǎn)遠(yuǎn)多于表本身的數(shù)據(jù)量

轉(zhuǎn)載于:https://www.cnblogs.com/danhuangpai/p/10095001.html

總結(jié)

以上是生活随笔為你收集整理的mysql 查询优化 ~ explain与索引失效的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。