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

總結

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

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