前言
今天咱们来说讲如何优化MySQL的性能，主要从索引方面优化。下期文章讲讲MySQL慢查询日志，咱们是依据慢查询日志来判断哪条SQL语句有问题，而后再进行优化，敬请期待MySQL慢查询日志篇算法
建表
优化一：所有用到索引
介绍
创建的复合索引包含了几个字段，查询的时候最好能所有用到，并且严格按照索引顺序，这样查询效率是最高的。（最理想状况，具体状况具体分析）sql
SQL 案例
优化二：最左前缀法则
介绍
若是创建的是复合索引，索引的顺序要按照创建时的顺序，即从左到右，如：a->b->c（和 B+树的数据结构有关）数据库
无效索引举例
- a->c：a 有效，c 无效
- b->c：b、c 都无效
- c：c 无效
SQL 案例
优化三：不要对索引作如下处理
如下用法会致使索引失效
- 计算，如：+、-、*、/、!=、<>、is null、is not null、or
- 函数，如：sum()、round()等等
- 手动/自动类型转换，如：id = “1”，原本是数字，被写成字符串了
SQL 案例
优化四：索引不要放在范围查询右边
举例
好比复合索引：a->b->c，当 where a="" and b>10 and 3=""，这时候只能用到 a 和 b，c 用不到索引，由于在范围以后索引都失效（和 B+树结构有关）数据结构
SQL 案例
优化五：减小 select * 的使用
使用覆盖索引
即：select 查询字段和 where 中使用的索引字段一致。并发
SQL 案例
优化六：like 模糊搜索
失效状况
- like “%张三%”
- like “%张三”
解决方案
- 使用复合索引，即 like 字段是 select 的查询字段，如：select name from table where name like “%张三%”
- 使用 like “张三%”
SQL 案例
优化七：order by 优化
当查询语句中使用 order by 进行排序时，若是没有使用索引进行排序，会出现 filesort 文件内排序，这种状况再数据量大或者并发高的时候，会有性能问题，须要优化。函数
filesort 出现的状况举例
- order by 字段不是索引字段
- order by 字段是索引字段，可是 select 中没有使用覆盖索引，如：select * from staffs order by age asc;
- order by 中同时存在 ASC 升序排序和 DESC 降序排序，如：select a, b from staffs order by a desc, b asc;
- order by 多个字段排序时，不是按照索引顺序进行 order by，即不是按照最左前缀法则，如：select a, b from staffs order by b asc, a asc;
索引层面解决方法
- 使用主键索引排序
- 按照最左前缀法则，而且使用覆盖索引排序，多个字段排序时，保持排序方向一致
- 在 SQL 语句中强制指定使用某索引，force index(索引名字)
- 不在数据库中排序，在代码层面排序
order by 排序算法
- 双路排序Mysql4.1 以前是使用双路排序，字面的意思就是两次扫描磁盘，最终获得数据，读取行指针和 ORDER BY 列，对他们进行排序，而后扫描已经排好序的列表，按照列表中的值从新从列表中读取对数据输出。也就是从磁盘读取排序字段，在 buffer 进行排序，再从磁盘读取其余字段。
文件的磁盘 IO 很是耗时的，因此在 Mysql4.1 以后，出现了第二种算法，就是单路排序。高并发
- 单路排序从磁盘读取查询须要的全部列，按照 orderby 列在 buffer 对它们进行排序，而后扫描排序后的列表进行输出， 它的效率更快一些，避免了第二次读取数据，而且把随机 IO 变成顺序 IO，可是它会使用更多的空间， 由于它把每一行都保存在内存中了。
当咱们无可避免要使用排序时，索引层面无法在优化的时候又该怎么办呢？尽量让 MySQL 选择使用第二种单路算法来进行排序。这样能够减小大量的随机 IO 操做,很大幅度地提升排序工做的效率。下面看看单路排序优化须要注意的点性能
单路排序优化点
- 增大 max_length_for_sort_data在 MySQL 中,决定使用"双路排序"算法仍是"单路排序"算法是经过参数 maxlength_for sort_data 来决定的。当全部返回字段的最大长度小于这个参数值时,MySQL 就会选择"单路排序"算法,反之,则选择"多路排序"算法。因此,若是有充足的内存让 MySQL 存放需要返回的非排序字段,就能够加大这个参数的值来让 MySQL 选择使用"单路排序"算法。
- 去掉没必要要的返回字段，避免select *当内存不是很充裕时,不能简单地经过强行加大上面的参数来强迫 MySQL 去使用"单路排序"算法,不然可能会形成 MySQL 不得不将数据分红不少段,而后进行排序,这样可能会得不偿失。此时就需要去掉没必要要的返回字段,让返回结果长度适应 max_length_for_sort_data 参数的限制。
- 增大 sort_buffer_size 参数设置这个值若是太小的话,再加上你一次返回的条数过多,那么极可能就会分不少次进行排序,而后最后将每次的排序结果再串联起来,这样就会慢慢,增大 sort_buffer_size 并非为了让 MySQL 选择"单路排序"算法,而是为了让 MySQL 尽可能减小在排序过程当中对需要排序的数据进行分段,由于分段会形成 MySQL 不得不使用临时表来进行交换排序。
可是sort_buffer_size 不是越大越好：优化
- Sort_Buffer_Size 是一个 connection 级参数,在每一个 connection 第一次须要使用这个 buffer 的时候,一次性分配设置的内存。
- Sort_Buffer_Size 并非越大越好,因为是 connection 级的参数,过大的设置和高并发可能会耗尽系统内存资源。
- 听说 Sort_Buffer_Size 超过 2M 的时候,就会使用 mmap() 而不是 malloc() 来进行内存分配,致使效率下降。
优化八：group by
其原理也是先排序后分组，其优化方式可参考order by。where高于having,能写在where限定的条件就不要去having限定了。spa