這篇文章主要介紹“MySQL in慢查詢?nèi)绾蝺?yōu)化”，在日常操作中，相信很多人在mysql in慢查詢?nèi)绾蝺?yōu)化問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”mysql in慢查詢?nèi)绾蝺?yōu)化”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！
成都創(chuàng)新互聯(lián)專注于工布江達(dá)網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供工布江達(dá)營銷型網(wǎng)站建設(shè)，工布江達(dá)網(wǎng)站制作、工布江達(dá)網(wǎng)頁設(shè)計(jì)、工布江達(dá)網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造工布江達(dá)網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供工布江達(dá)網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
第一步、分析SQL
***from event i left join project p on i.project_id = p.project_code left join dict d on i.type_id = d.id left join record re on re.incident_id = i.id left join type it on it.id = i.type_id where i.version_flag = 0 and i.flow_id in (大量條件)***復(fù)制代碼
當(dāng)flow_id in接入大量條件，sql直接變慢，由之前的80ms到5.8秒，另外此處，關(guān)聯(lián)表較多。
第二步、檢查索引，執(zhí)行explain
當(dāng)我們檢查索引發(fā)現(xiàn)re.incident_id和i.flow_id并沒有走索引，so，大喜，問題找到了，建索引；然而執(zhí)行SQL，發(fā)現(xiàn)并卵！機(jī)智如我，直接打開explain，發(fā)現(xiàn)record的type為all，赤裸裸的沒走索引啊。
第三步、檢查兩個(gè)關(guān)聯(lián)字段的字段類型、長度和字符類型是否一致
當(dāng)比較字段類型和字段長度發(fā)現(xiàn)完全一致，短暫的郁悶之后，發(fā)現(xiàn)了新的線索——
event表的id的字符類型為：
record表的incident_id的字符類型為：
果斷統(tǒng)一使用utf8mb4與項(xiàng)目組保持統(tǒng)一；再次explain，耗時(shí)瞬間低至1秒之內(nèi)，手工。
第四步、強(qiáng)制使用索引操作
mysql在一個(gè)表如果索引基數(shù)過小的情況下默認(rèn)會(huì)走全文搜索，所以對(duì)于表業(yè)務(wù)量過大，但是索引字段基本上為同一數(shù)據(jù)或null的情況 還是需要在sql中寫死強(qiáng)制索引;在sql中使用強(qiáng)制索引解決辦法 left join 后添加 force index(alarm_id)——
第五步、IN通常是走索引的
只有當(dāng)IN后面的數(shù)據(jù)在數(shù)據(jù)表中超過30% 的匹配時(shí)是全表掃描，不走索引，因此IN走不走索引和后面的數(shù)據(jù)量有關(guān)系。 in大量數(shù)據(jù)可以使用left join來處理。
到此，關(guān)于“mysql in慢查詢?nèi)绾蝺?yōu)化”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
