Mysql查询性能优化之analyze+optimize+index

一、解决什么问题？

前提： 两个数据库（开发和测试环境）拥有三张完全一样的表（索引、字段一样），其中每个表的数据在50万左右。
操作：在两个数据库上执行一条sql语句（该sql语句针对三张表进行了inner join 查询）
问题：在其中一个数据库执行sql语句查询只需要176ms，而在另一个数据库执行sql确需要18s

mysql1.png

二、分析过程

1. 通过explain分析sql发现相同的sql语句在不同的数据库上使用了不同的驱动表，mysql的内部优化使执行顺序发生了变化,其中执行较快的使用了pi作为驱动表，执行较慢的使用了zo作为驱动表，并且使用了不同的索引
2. 既然如此进一步分析mysql的驱动规则：

1. 使用left join时 左表是驱动表
2. 使用right join时 右表是驱动表
3. 使用inner join时 小表驱动大表（在被驱动表建立索引，才能使用到索引）
   驱动表可以直接排序，而非驱动表的排序需要对循环查询的合并结果进行排序

3. 既然发现了是驱动表以及索引以及排序导致的问题，目前通过强制驱动表(straight_join)、强制索引、或者修改排序使用驱动表排序解决问题，但是mysql为什么会被优化成现在的样子仍然是一个迷......

--- 强制索引
select *
from table_1 force index ()
inner join table_2;

4. 通过执行analyze table解决问题

• analyze用来修复表的统计信息包括索引

mysql的optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了

• Optimize table 是减少存储碎片的

重新利用未使用的空间，并整理数据文件的碎片，Optimize在执行时会锁表

三、总结

1. 经常更新的数据库应该定期执行analyze和Optimize
2. 一些数据库创建索引的经验

1. 索引实际上也是一张表，保存了主键和索引字段，并指向实体表的记录
2. 索引提高了数据检索的效率，但同时会降低更新表的速度
3. 主键自动建立唯一索引
4. 频繁作为查询条件的字段应该创建索引
5. 查询外键关系建立索引
6. 查询排序、分组字段建立索引
7. 表记录太少、数据重复、频繁更新字段不适合创建索引
8. 唯一性太差的字段不适合创建索引（状态）
9. 不会出现在where中的条件不适合创建索引
10. 尽量使用数据量小的创建索引（varchar(10)创建比varhchar(100)好）
11. 删除不再使用的索引
12. 经常和其他表连接的表，在连接字段上应该创建索引
13. 模糊匹配不能使用索引如 '%%', 'X%'可以使用索引
14. mysql的索引根据查询的内容使用不同的索引，有时候可能会导致索引使用不上，针对多表链接查询建议先根据条件查询出id，在通过in 来查询出所需要的内容

4. 最近使用mysql查询特别是几十张表join的时候往往莫名其妙其中一张表的索引就使用不上了，然后查询就超级慢，去掉这一张表就很快了（通过14的方式解决了这个问题，但是仍然很懵逼为什么使用不上索引）
5. mysql的优化只能说：路漫漫其修远兮，吾将上线而求索！