关于mysql 优化的日常记录

记录日常工作中优化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 表 一步一步判断哪里慢