现在常看到的文章就是MySQL性能优化，为什么需要优化呢？
因为：
- 数据库出现瓶颈，系统的吞吐量出现访问速度慢
- 随着应用程序的运行，数据库的中的数据会越来越多，处理时间变长
- 数据读写速度缓慢
总结：
like 前导符优化
like模糊查询形如'%AAA%'和'%AAA'将不会使用索引，但是业务上不可避免可能又需要使用到这种形式。
通常的方法有两种：
方案一：使用覆盖索引，即查询出的列只是用索引就可以获取，而无须查询表记录，这样也走了索引；
方案二：使用locate函数或者position函数代替like查询，如table.field like '%AAA%'可以改为locate('AAA', table.field) > 0或POSITION('AAA' IN table.field)>0
in 和 exist
如果查询的两个表大小相当，那么用in和exists差别不大。如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in：例如：表A（小表），表B（大表）
示例一：
image
示例二：
image
not in 和 not exist
如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not exist 的子查询依然能用到表上的索引。所以无论哪个表大，用not exists都比not in要快！
image
子查询优化
1）MySQL 5.6 之前的版本对子查询处理：不会将查询的结果集计算出来用作与其他表做join,outer表每扫描一条数据，子查询都会被重新执行一遍。
2）MySQL 5.6 对子查询的处理 ：将子查询的结果集 cache 到临时表里，临时表索引主要用来移除重复记录，并且随后也可能用于做join查询，这种技术在 5.6 中叫做物化的子查询，物化子查询可以看到select_type字段为subquery，而在 5.5 里为DEPENDENT SUBQUERY。
3）子查询一般都可以改成表的关联查询，子查询会有临时表的创建、销毁，效率低下。
image
straight_join
mysql hint：mysql 优化器在处理多表的关联的时候，很有可能会选择错误的驱动表进行关联，导致了关联次数的增加，从而使得sql语句执行变得非常的缓慢。
这个时候需要有经验的DBA进行判断，选择正确的驱动表，这个时候 straightjoin 就起了作用了，下面我们来看一看使用straight_join进行优化的案例。
尝试采用user表做驱动表，使用straight_join强制连接顺序：
image
高效分页
1）传统分页
select * from table limit 10000,10
2）limit原理
- Limit 10000,10
- 偏移量越大则越慢
3）推荐分页
image
复杂关联SQL的优化
1、首先查询返回的结果集，通常查询返回的结果集很少，是有优化的空间的。
2、通过查看执行计划，查看优化器选择的驱动表，从执行计划的rows可以大致反应出问题的所在。
3、搞清各表的关联关系，查看关联字段是否有合适的索引。
4、使用straight_join关键词来强制调整驱动表的选择，对优化的想法进行验证。
5、如果条件允许，对复杂的SQL进行拆分。尽可能越简单越好。
force index
有时优化器可能由于统计信息不准确等原因，没有选择最优的执行计划，可以人为改变mysql的执行计划，例如：
image
count的优化
按照效率排序的话，count(字段)<count(主键id)<count(1)≈count(*)，建议，尽量使用count(*)。
网友评论