MySQLHINT:Straight_JOIN
來源:懂視網(wǎng)
責(zé)編:小采
時間:2020-11-09 14:02:40
MySQLHINT:Straight_JOIN
MySQLHINT:Straight_JOIN:來自生產(chǎn)環(huán)境的朋友、可能都會碰到: 原本運(yùn)行良好的查詢語句,過了一段時間后,可能會突然變得很糟糕 一個很大可能的原因就是數(shù)據(jù)分布情況發(fā)生了變化 從而導(dǎo)致MySQL優(yōu)化器對驅(qū)動表的選擇發(fā)生了變化,進(jìn)而出現(xiàn)索引失效的情況 所以、閑著蛋疼喝咖啡的時候、應(yīng)
導(dǎo)讀MySQLHINT:Straight_JOIN:來自生產(chǎn)環(huán)境的朋友、可能都會碰到: 原本運(yùn)行良好的查詢語句,過了一段時間后,可能會突然變得很糟糕 一個很大可能的原因就是數(shù)據(jù)分布情況發(fā)生了變化 從而導(dǎo)致MySQL優(yōu)化器對驅(qū)動表的選擇發(fā)生了變化,進(jìn)而出現(xiàn)索引失效的情況 所以、閑著蛋疼喝咖啡的時候、應(yīng)

來自生產(chǎn)環(huán)境的朋友、可能都會碰到: 原本運(yùn)行良好的查詢語句,過了一段時間后,可能會突然變得很糟糕 一個很大可能的原因就是數(shù)據(jù)分布情況發(fā)生了變化 從而導(dǎo)致MySQL優(yōu)化器對驅(qū)動表的選擇發(fā)生了變化,進(jìn)而出現(xiàn)索引失效的情況 所以、閑著蛋疼喝咖啡的時候、應(yīng)
來自生產(chǎn)環(huán)境的朋友、可能都會碰到:
原本運(yùn)行良好的查詢語句,過了一段時間后,可能會突然變得很糟糕
一個很大可能的原因就是數(shù)據(jù)分布情況發(fā)生了變化
從而導(dǎo)致MySQL優(yōu)化器對驅(qū)動表的選擇發(fā)生了變化,進(jìn)而出現(xiàn)索引失效的情況
所以、閑著蛋疼喝咖啡的時候、應(yīng)該多收集兩下表的統(tǒng)計信息
這個時候、Straight_JOIN 閃亮登場
MySQL 只支持 Nested Loop Join、關(guān)于這個Nested JOIN的詳細(xì)用法請參閱偶之前blog:點(diǎn)擊打開鏈接
和Oracle對比下、不然得知、Straight_JOIN相當(dāng)于Oracle里面的:USE_NL、所以、原理和適用上大概都是相同的、
不過、對于驅(qū)動表的選擇、MySQL 優(yōu)化器可能沒有Oracle那般智能、MySQL采用簡單粗暴的方法:
哪個表的結(jié)果集小,就以哪個表為驅(qū)動表
偶趕腳有2 種原因可令你選擇 Straight_JOIN
① MySQL 優(yōu)化器不給力、錯誤選擇驅(qū)動表
② Nested Loop Join 的適用場景:
==>一般用在連接的表中有索引,并且索引選擇性較好(也就是Selectivity接近1)的時候
==>也就是驅(qū)動表的記錄集比較小(<10000)而且inner表需要有有效的訪問方法(Index)
一般的優(yōu)化操作:
① show full processlist; <===查找TOP-SQL
② explain + TOP-SQL ; <===查詢SQL 執(zhí)行計劃
注意:在EXPLAIN結(jié)果中,第一行出現(xiàn)的表就是驅(qū)動表
一個經(jīng)典優(yōu)化例子:
當(dāng)explian輸出結(jié)果中含:「Using filesort」,甚至「Using temporary」
我們就該擦亮雙眼、像打了雞血一樣、保持時刻優(yōu)化的姿態(tài)
此刻的優(yōu)化就容易多了、盡可能保證排序字段在驅(qū)動表中
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
MySQLHINT:Straight_JOIN
MySQLHINT:Straight_JOIN:來自生產(chǎn)環(huán)境的朋友、可能都會碰到: 原本運(yùn)行良好的查詢語句,過了一段時間后,可能會突然變得很糟糕 一個很大可能的原因就是數(shù)據(jù)分布情況發(fā)生了變化 從而導(dǎo)致MySQL優(yōu)化器對驅(qū)動表的選擇發(fā)生了變化,進(jìn)而出現(xiàn)索引失效的情況 所以、閑著蛋疼喝咖啡的時候、應(yīng)