MySQL优化心得

一打开科技类论坛，最常看到的文章主题就是MySQL性能优化了，为何要优化呢？

由于：

• 数据库出现瓶颈，系统的吞吐量出现访问速度慢
• 随着应用程序的运行，数据库的中的数据会愈来愈多，处理时间变长
• 数据读写速度缓慢

就是我们说的“性能问题”，程序员一遇到它老是焦头烂额！

今天小编对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（大表）

示例一：

示例二：

not in 和 not exist

若是查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not exist 的子查询依然能用到表上的索引。因此不管哪一个表大，用not exists都比not in要快！

子查询优化

一、MySQL 5.6 以前的版本对子查询处理：不会将查询的结果集计算出来用做与其余表作join,outer表每扫描一条数据，子查询都会被从新执行一遍。

二、MySQL 5.6 对子查询的处理 ：将子查询的结果集 cache 到临时表里，临时表索引主要用来移除重复记录，而且随后也可能用于作join查询，这种技术在 5.6 中叫作物化的子查询，物化子查询能够看到select_type字段为subquery，而在 5.5 里为DEPENDENT SUBQUERY。

三、子查询通常均可以改为表的关联查询，子查询会有临时表的建立、销毁，效率低下。

straight_join

mysql hint：

Mysql 优化器在处理多表的关联的时候，颇有可能会选择错误的驱动表进行关联，致使了关联次数的增长，从而使得sql语句执行变得很是的缓慢。

这个时候须要有经验的DBA进行判断，选择正确的驱动表，这个时候 straightjoin 就起了做用了，下面咱们来看一看使用straight_join进行优化的案例：

尝试采用user表作驱动表，使用straight_join强制链接顺序：

高效分页

传统分页

select * from table limit 10000,10

limit原理

（1） Limit 10000,10
（2）偏移量越大则越慢

推荐分页

复杂关联SQL的优化

一、首先查询返回的结果集，一般查询返回的结果集不多，是有优化的空间的。

二、经过查看执行计划，查看优化器选择的驱动表，从执行计划的rows能够大体反应出问题的所在。

三、搞清各表的关联关系，查看关联字段是否有合适的索引。

四、使用straight_join关键词来强制调整驱动表的选择，对优化的想法进行验证。

五、若是条件容许，对复杂的SQL进行拆分。尽量越简单越好。

force index

有时优化器可能因为统计信息不许确等缘由，没有选择最优的执行计划，能够人为改变mysql的执行计划，例如：

count的优化

按照效率排序的话，count(字段)<count(主键id)<count(1)≈count(*)，因此我建议你，尽可能使用count(*)。

总结

MySQL 性能优化 最主要是理解 innodb 的索引原理及结构及 SQL 的执行计划，在不断累积经验的基础上熟能生巧。