索引优化分析（二）
1、SQL语句的性能分析（Explain）
一、查看SQL语句的执行计划
使用explain关键词能够模拟优化器执行SQL查询语句，从而知道Mysql是如何处理sql语句，分析出查询语句或表结构的性能瓶颈，使用语法以下：java
explain + sql语句：explain select * from table_name
查询结果以下：mysql
二、Explain+SQL语句结果分析
（1）id：selectct 查询的序列号，包含一组数字，表示查询中执行select子句或操做表的顺序（查询顺序）sql
（a）id相同，执行顺序由上至下 （b）id不一样，若是是子查询，id的序号会递增，id值越大，优先级越高，越先被执行 （c）id相同不一样，同时存在
（2）select_type：表示查询的类型缓存
一、SIMPLE：简单的select查询，查询中不包含子查询或union 二、PRIMARY：查询中若包含任何复杂的子部分，最外层查询则标记为primary 三、SUBQUERY：在select或where列表中包含了子查询 四、DERIVED：在from列表中包含的子查询被标记为derived(衍生)，mysql会递归执行这些子查询，把结果放在临时表里 五、UNION：若第二个select出如今union以后，则被标记为union 六、UNION RESULT：从union表中获取结果的select
（3）table：显示这一行的数据是于哪张表的来自bash
（4） partitions：使用的哪一个分区，须要结合表分区才能够看到函数
（5）type：表示按某种类型来查询，例如按照索引类型查找，按照范围查找性能
该值表示查询的sql语句好坏，从最好到最差依次为：system>const>eq_ref>ref>range>index>ALLmysql索引
一、system：表中只有一行记录，这是const类型的特列 二、const：表示经过索引一次就能查到了，const用于比较primary key或unique索引，由于只匹配一行数据，因此很快，如将主键置于where列表中，mysql就能将该查询转换为一个常量 三、eq_ref：惟一性索引扫描，对于每一个索引键，表中只有一条与之匹配常见于主键或惟一索引扫描 四、ref：非惟一性索引扫描，返回匹配某个单独值的全部行，本质上也是一种索引访问，它返回全部匹配某个单独的行，然而，它可能找到多个符合条件的行，因此它应该属于查找和扫描的混合体 五、range：只检索给定范围的行，使用一个索引来选择行，通常就是在where语句中出现betwent、<、>、in等查询中，这种范围扫描索引扫描比全表扫描要好，由于它只须要开始与索引的某一个点，而结束于另外一个点，不用扫描所有索引 六、index：full index scan，index与all区别为index类型只遍历索引树，这一般比all快，由于索引文件一般比数据文件小 七、all：full table scan，将遍历全表以找到匹配的行 备注：通常来讲，保证查询至少到达range级别，最好能到达ref
（6）possible_keys：显示可能应用在该表中的索引，若是是多个索引的话，用逗号隔开，但查询时不必定被实际应用到优化
（7）key：查询时实际使用到的索引，若是为null，则没有使用到索引；若查询时使用了覆盖索引，则该索引和查询的select字段重叠spa
（8）key_len：表示索引中使用的字节数，可经过该列计算查询中使用的索引长的，长度越短越好
（9）ref：显示索引的哪一列被使用了，若是可能的话，是一个常数，哪些列或常数被用于查找索引列上的值
（10）rows：查询时大体估算出找到所需的记录，所须要读取的总行数
（11）filtered：经过过滤条件以后对比总数的百分比
（12）Extra：包含不适合在其余列中显示但十分重要的额外信息
- Using filesort：说明mysql会对数据使用的一个外部的索引排序，而不是按照表内的索引顺序进行读取，mysql中没法利用索引完成的排序操做称为"文件排序"，出现该关键词，须要优化处理。（组合索引排序时，不能跳过前面索引排序，按索引顺序进行排序，不产生索引排序冲突）
- Using temporary：使用了临时表保存中间结果，mysql在对查询结果排序时使用了临时表，常见于排序order by和分组查询group by（通常group by都会排序产生临时表）。出现该关键词，须要优化处理。
- Using index：表示相应的select操做中使用了覆盖索引，避免访问了表的数据行，效率不错。覆盖索引：就是select的数据列只用从索引中就可以取得，没必要读取数据行，mysql能够利用索引返回select列表中的字段，而没必要根据索引（物理地址）再次读取数据文件，即查询列要被所建的索引覆盖。
- Using where：代表使用了where过滤。
- Using join buffer：使用了链接缓存。
- impossible where ：where子句的值老是false，不能用来获取任何数据，即条件永远不成立。
- distinct：优化distinct操做，在找到第一匹配的数据后当即中止找一样值的动做。
三、Explain性能分析的做用
（1）了解表的读取顺序（表的执行顺序）>id
（2）数据读取操做的操做类型（如：子查询等）>select_type、type
（3）查询中哪些索引可使用 >possible_keys
（4）查询中哪些索引被实际使用到 >key
（5）表之间的引用 >table
（6）每张表有多少行被优化器查询 >rows
2、索引优化
一、索引失效状况以下类型（应该避免）
（1）全值匹配我最爱，即where条件按照索引的顺序查询，效果最佳（组合索引时，最前索引不能丢） （2）最佳左前辍法则，若是为组合索引，要遵照最左前辍法则，查询时从索引的最左前列开始而且不跳过索引中的列（不按索引顺序检索容易致使索引失效） （3）不在索引列上作任何的操做（计算、函数、类型转换等），会致使索引失效而转向全表扫描 （4）存储引擎不能使用索引中范围条件右边的列，即索引中查询条件存在范围时，索引将会失效 （5）尽可能使用覆盖索引，即只访问索引的查询（索引列跟查询列一致），减小select * （6）mysql在使用不等于（!= 或<>）的时候没法使用索引会致使全表扫描（可经过覆盖索引方式解决） （7）is null或is not null也是没法使用索引的（可经过覆盖索引方式解决） （8）like以通配符开头（'%test%'）,mysql索引失效会变成全表扫描，可是索引支持右模糊查询，即like 'test%'（可经过覆盖索引方式解决） （9）字符串不加单引号索引失效（mysql会自动类型转换，致使索引失效） （10）少用or，用它来链接时会索引失效（可经过覆盖索引方式解决）
二、索引建立、优化建议
（1）常常做为条件的字段应添加索引，多个则建立组合索引 （2）多表关联查询时，保证join语句中被驱动表上join条件字段已经被索引（建立索引） （3）永远用小结果集驱动大的结果集（即小表驱动大表）