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

總結

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

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