記錄日常工作中優(yōu)化sql的一些注意事項(xiàng)
1、left join 會(huì)比 inner join 慢 （left join 要讓小表做主表，在關(guān)聯(lián)條件上添加索引），inner join 中自動(dòng)的
2、注意 表結(jié)構(gòu)的編碼方式會(huì)讓 left 等不走索引
3、對于大表來說BETWEEN and、 >、<等運(yùn)算符來說可能不走索引 （會(huì)導(dǎo)致CBO優(yōu)化器計(jì)算走索引花費(fèi)大于走全表） 不妨加個(gè) limit 0，100 然后就走索引了。
4、FORCE INDEX (time) 強(qiáng)制走索引（對于between 這種來說 也起不了很好的效果，但是效果也是有的）
5、FORCE INDEX (time) 也不能隨便使用 ，可能導(dǎo)致其他索引失效 （有可能）
6、注意表、字段的編碼保持一致
7、一般情況下，INNER JOIN 比 LEFT JOIN 返回更少的數(shù)據(jù)，因此查詢效率應(yīng)該更高。但是如果關(guān)聯(lián)的表中有GROUP BY那么就要注意了，因?yàn)槲覀冇?)括住的sql不一定會(huì)做為一個(gè)整體去執(zhí)行的，所以有時(shí)在返回的數(shù)據(jù)一樣的情況下，LEFT JOIN 比 INNER JOIN 執(zhí)行的是更快的，而具體什么情況下會(huì)這樣，就需要我們參考兩者的執(zhí)行計(jì)劃進(jìn)行對比了，
8、明確一點(diǎn)就是主鍵索引是比普通索引要快的
9、記錄一下遇到的問題（有個(gè)sql 里面既有inner join 又有l(wèi)eft join）傳統(tǒng)思想是少關(guān)聯(lián)一個(gè)表就會(huì)快很多，但是在我left join 大表之后發(fā)現(xiàn)反而變更快了，explain 了一下 不加最后left join 表的時(shí)候掃描出的行數(shù)(估算的行數(shù)) 反而會(huì)比 加了個(gè)LEFT join 的行數(shù)多，這很奇怪。（在這里有where 條件 條件上有與關(guān)聯(lián)字段的聯(lián)合索引），于是把where 中關(guān)聯(lián)的索引字段查詢條件刪除后變跟不加LEFT JOIN explain的行數(shù)一樣了。這時(shí)候發(fā)現(xiàn)問題， 很有可能explain 走的時(shí)候會(huì)先走where的普通索引進(jìn)行查找（這時(shí)候的數(shù)據(jù)基數(shù)并不少）再與其他的一關(guān)聯(lián)，就很有可能影響的行數(shù)超級(jí)多，反而比LEFT join關(guān)聯(lián)大表的少。
（explain 的解析字段參考 https://www.cnblogs.com/tufujie/p/9413852.html）
10、索引并不是多加就好，因?yàn)槲覀兗佣嗔怂饕赡苡械木蜁?huì)走普通索引，這樣效率就會(huì)差很多
11、order by 的字段也要加上索引
12、有時(shí)候where 里面單個(gè)字段不走索引，還有其他的where 條件的話 試一下聯(lián)合索引不行的話就加上FORCE INDEX
13、對于大的sql 關(guān)聯(lián)很多表的 需要一步一步刪除來判斷在哪里慢，先刪除排序、查詢字段的子查詢、再逐步刪除一些沒有關(guān)系的表 left join 表 一步一步判斷哪里慢

總結(jié)

以上是生活随笔為你收集整理的关于mysql 优化的日常记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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