优化策略explain

• explain +sql
• 相关字段id,select_type,type,prossible_keys,key,key_len,ref,rows,extra id:查询顺序
• id相同时，从上往下顺序执行(表的执行顺序，普通连接查询因数量的个数改变而改变：笛卡尔积顺序）
• id不同时，表示包含子查询，id 值会递增。id 值越大，优先级越高，越先执行。本质是先查内层，再查外层。 select_type:查询类型
• SIMPLE：简单查询，不包含 UNION 或者子查询。
• PRIMARY：查询中如果包含子查询或其他部分，外层的 SELECT 将被标记为 PRIMARY。
• SUBQUERY：所有包含子查询中的子查询。
• DERIVED：衍生查询（临时表），在 FROM 中出现的子查询将被标记为 DERIVED。
• • a:在from子查询中只有一张表。
• • b:的from子查询中，如果有table1 union table2 则table1 就是derived，第二张则是union。
• UNION：在 UNION 语句中，UNION 之后出现的 SELECT。
• UNION RESULT：UNION 查询的结果。 type：索引类型
• 相关字段：system>const>eq_ref>ref>range>index>all
• 其中system,const只是理想情况；实际上达到ref>range
• system(忽略）:只有一条数据的系统表或衍生表中只有一条数据的主查询。
• const:仅仅能查到一条数据的SQL，主键查询或唯一索引单值查询。
• eq_ref:当连表查询时，前一张表的行在当前这张表中只有一行与之对应。是除了 system 与 const 之外最好的 join 方式，常用与使用主键或唯一索引的所有字段作为连表条件。
• ref:使用普通索引（非唯一索引）查询。返回匹配的所有行（0或多）
• range：检索指定范围的行，where后面是一个范围查询（between,>,<,>=,<=,in:有时会失效，从而降级为all )
• index：查询所有索引数据
• all：查询表中全部数据 possible_type：可能用的索引，是预测要使用。
• 如果possible_key和key是NULL，则表明没用索引 key:实际使用的索引
• 如果possible_key和key是NULL，则表明没用索引 key_len:索引的长度
• 用于判断复合索引是否被完全使用。
• 如果索引字段可以为NULL，则+1个字节(固定长度字段），+2（可变长度字段）

ref:指明当前表所参照的字段

• 常量则为const。其他为参照的字段 rows:被索引优化查询的数据个数
• 实际使用索引查询到的个数 extra:
• using filesort:使用文件索引，性能消耗大，需要额外一次排序或查询,常见于order by 语句
• • 单列索引：如果排序和查找是一个字段，则不会出现using filesort，如果排序和查找不是同一个字段，则会出现。优化：where什么字段就order by什么字段
• • 复合索引：跨列查询(where和order by 加起来）则会出现using filesort，优化：where和order by 按照符合索引顺序,最好优化
• using temporary:性能损耗大，用到了临时表，常见与group by语句。一般查询的列和分组的列不一致，优化：查询什么列就用什么列分组
• using where:需要使用回表查询。需要查询用到的索引之外的字段。
• using index:性能提升，索引覆盖。此次查询不读取原文件，只是从索引中取数据，不回表查询其他列数据。只要使用的列全部在索引中，就是索引覆盖。
• Impossiable where:查询条件永远为false。
• using join buffer：mysql使用了连接缓存，代表sql写的太差。