MySQL性能优化之索引与执行计划

SQL执行过程

• 通过网络的通讯协议接收客户端传入的SQL
• 查看该SQL对应的结果在查询缓存中是否存在
  • 存在则直接返回结果
  • 不存在则继续往下走
• 由解析器来解析当前SQL，最终形成初步的解析树
• 再由预处理器对解析树进行调整，完成占位符赋值等操作
• 查询优化器对最终的解析树进行优化，包括调整SQL顺序,是否使用索引等
• 根据优化后的结果得出查询语句的执行计划,就是查询数据的具体实施方案,交给查询的执行引擎
• 查询执行引擎调用存储引擎提供的API，最后由存储引擎来完成数据的查询，然后返回结果

sql被解析后的顺序:

from…on…left…where…group by…having…select…order by…limit

分析执行计划

explain 查询sql  //用于显示SQL执行信息参数

各列的含义:

• id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.
  • 如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
  • id如果相同，可以认为是一组，从上往下顺序执行；
• select_type: SELECT 查询的类型.
  • SIMPLE(简单SELECT,不使用UNION或子查询等)
  • PRIMARY(查询中若包含任何复杂的子部分,最外层的select被标记为PRIMARY)
  • UNION(UNION中的第二个或后面的SELECT语句)
  • DEPENDENT UNION(UNION中的第二个或后面的SELECT语句，取决于外面的查询)
  • UNION RESULT(UNION的结果)
  • SUBQUERY(子查询中的第一个SELECT)
  • DEPENDENT SUBQUERY(子查询中的第一个SELECT，取决于外面的查询)
  • DERIVED(派生表的SELECT, FROM子句的子查询)
  • UNCACHEABLE SUBQUERY(一个子查询的结果不能被缓存，必须重新评估外链接的第一行)
• table: 查询的是哪个表
• type: 数据访问/读取操作类型
  • 结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL .一般来说，得保证查询至少达到range级别，最好能达到ref。
  • eq_ref: 使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配
  • ref: 使用非唯一性索引做查询,返回匹配的记录行
  • range: 使用了索引做范围查询
  • index: 使用了索引的全文查询
• possible_keys: 此次查询中可能选用的索引,但不一定被查询使用.
• key: 此次查询中确切使用到的索引.
• key_len: 索引中使用的字节数,为最大可能长度，并非实际使用长度,不损失精确性的情况下，长度越短越好
• ref: 哪些列或常量被用于查找索引列上的值
• rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
• extra: 额外的信息
  • Using filesort: MySQL中无法利用索引完成排序,需要额外进行一次排序(影响性能)
  • Using temporary: MySQL需要使用临时表来存储结果集&#