MySQL的优化

MySQL的优化

SQL优化步骤

1、先定位慢查询的sql（慢查询日志、spl、spf）
2、分析sql慢的原因（explain type key extra....） 
    * type 级别提高（级别记住）
3、优化sql（加索引、改sql）
4、验证是否优化生效

Mysql从5.0.37版本开始增加了对 show profiles 和 show profile 语句的支持。show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了
默认profiling是关闭的，可以通过set语句在Session级别开启profiling
set profiling=1; //开启profiling 开关；
Sending data 状态表示MySQL线程开始访问数据行并把结果返回给客户端，而不仅仅是返回个客户端。由于在Sending data状态下，
MySQL线程往往需要做大量的磁盘读取操作，所以经常是整各查询中耗时最长的状态。
在获取到最消耗时间的线程状态后，MySQL支持进一步选择all、cpu、block io 、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间

避免索引失效现象总结

1. 不要在索引列上进行运算操作， 索引将失效

2. 在查询是，没有对字符串加单引号，MySQL的查询优化器，会自动的进行类型转换，造成索引失效。

3. 尽量使用覆盖索引（只访问索引的查询（索引列完全包含查询列）），减少select * 。

4. 用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。

5. 以%开头的Like模糊查询，索引失效。
   如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

6. in 走索引， not in 索引失效。

7. 单列索引和复合索引。尽量使用复合索引，而少使用单列索引 。

最左匹配法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。
* 使用复合索引代替单值索引
* 不要为了优化还写sql
4、其它优化（了解）
* SQL优化
* 海量数据的分页优化
在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。
* 模糊查询索引失效现象

type 显示的是访问类型，是较为重要的一个指标，可取值为：
type 含义

type	含义
NULL	MySQL不访问任何表，索引，直接返回结果
system	表只有一行记录(等于系统表)，这是const类型的特例，一般不会出现
const	表示通过索引一次就找到了，const 用于比较primary key 或者 unique 索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL 就能将该查询转换为一个常亮。const于将 “主键” 或 “唯一” 索引的所有部分与常量值进行比较
eq_ref	类似ref，区别在于使用的是唯一索引，使用主键的关联查询，关联查询出的记录只有一条。常见于主键或唯一索引扫描
ref	非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，返回所有匹配某个单独值的所有行（多个）
range	只检索给定返回的行，使用一个索引来选择行。 where 之后出现 between ， < , > , in 等操作。
index	index 与 ALL的区别为 index 类型只是遍历了索引树， 通常比ALL 快， ALL 是遍历数据文件。
all	将遍历全表以找到匹配的行

possible_keys : 显示可能应用在这张表的索引， 一个或多个。
key ： 实际使用的索引， 如果为NULL， 则没有使用索引。
key_len : 表示索引中使用的字节数， 该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下， 长度越短越好 。

sql优化就是索引.

1. 定位抵效率的sql语句
   a. 慢查询日志: 通过慢查询日志,定义哪些执行效率较低的SQL语句,
   ⅰ. long_query_time
   b. show processlist: 实时地查看SQL地执行情况,同时对一些锁表操作进行优化
2. 分析慢查询:
   a. 在查询语句前加 explani