建站
咨詢
售后
建站咨詢
新聞中心
本網(wǎng)站系統(tǒng)上線至今，數(shù)據(jù)量已經(jīng)不知不覺上到500M，近8W記錄了。涉及數(shù)據(jù)庫操作的基本都是變得很慢了，用的人都會(huì)覺得躁火~~然后把這個(gè)情況在群里一貼，包括機(jī)器配置什么的一說，馬上就有群友發(fā)話了，而且?guī)臀掖_定了不是機(jī)器配置的問題，“深圳-槍手”熱心人他的機(jī)器512內(nèi)存過百W的數(shù)據(jù)里也跑得飛快，甚至跟那些幾W塊的機(jī)器一樣牛(吹過頭了)，呵呵~~~
創(chuàng)新互聯(lián)是一家專注于成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)與策劃設(shè)計(jì),金臺(tái)網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:金臺(tái)等地區(qū)。金臺(tái)做網(wǎng)站價(jià)格咨詢:13518219792
在群友的分析指點(diǎn)下，嘗試把排序、條件等一個(gè)一個(gè)去除來做測(cè)試，結(jié)果發(fā)現(xiàn)問題就出在排序部分，去除排序的時(shí)候，執(zhí)行時(shí)間由原來的48秒變成0.3x秒，這是個(gè)什么檔次的變化呀~~看著這個(gè)結(jié)果我激動(dòng)ing.....
于是我把涉及排序的字段組成一個(gè)聯(lián)合索引alter table xx add index indexname(x1,x2,x3)，經(jīng)過2分鐘創(chuàng)建新索引之后再執(zhí)行同一個(gè)SQL語句，哇塞0.28S。爽
于是按照同樣的思路把其它幾個(gè)常用的SQL作了過些優(yōu)化，效果馬上見效
過了30分鐘再查slow sql記錄文件，不好了，發(fā)現(xiàn)原來一個(gè)好好的SQL變得灰常慢了，神馬情況?
幾經(jīng)分析和測(cè)試原來就是因?yàn)樘砑恿寺?lián)合索引的原因，而且這個(gè)SQL語句當(dāng)中有個(gè)or，當(dāng)把這個(gè)or改用union之后問題排除。
這回又得出一個(gè)心得：寫SQL的時(shí)候千萬別一時(shí)就手，隨便寫個(gè)就OK，那會(huì)為以為帶來很嚴(yán)重的后果。
再附上一段關(guān)于Where子句的執(zhí)行順序：
在用MySQL查詢數(shù)據(jù)庫的時(shí)候，連接了很多個(gè)用，發(fā)現(xiàn)非常慢。例如：
- SELECT ... WHERE p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1 AND p.products_id IN (472,474)
這樣查詢需要20多秒，雖然在各個(gè)字段上都建立了索引。用分析Explain SQL一分析，發(fā)現(xiàn)在***次分析過程中就返回了幾萬條數(shù)據(jù)：
WHERE p.languages_id = 1 ，然后再依次根據(jù)條件，縮小范圍。
而我改變一下WHERE 字段的位置之后，速度就有了明顯地提高：
- WHERE p.products_id IN (472,474) AND
- p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1
這樣，***次的條件是p.products_id IN (472,474)，它返回的結(jié)果只有不到10條，接下來還要根據(jù)其它的條件來過濾，自然在速度上有了較大的提升。
經(jīng)過實(shí)踐發(fā)現(xiàn)，不要以為WHERE中的字段順序無所謂，可以隨便放在哪，應(yīng)該盡可能地***次就過濾掉大部分無用的數(shù)據(jù)，只返回最小范圍的數(shù)據(jù)。
希望能幫到有同樣遭遇的朋友。
當(dāng)前標(biāo)題：MySQL:聯(lián)合索引與Where子句的優(yōu)化
當(dāng)前鏈接：http://www.dlmjj.cn/article/djpeogd.html
