震惊，竟然不能命中索引?

前言

数据库查询不走索引会导致全表扫描，效率低下。

举例

1. “列类型”与“where值类型”不符，不能命中索引，会导致全表扫描(full table scan)。

• 数据准备

create table t1 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;

insert into t1(cell) values ('111'),('222'),('333');
cell属性为varchar类型；
cell为主键，即聚簇索引(clustered index)；

• 测试语句

explain select * from t1 where cell=111;
explain select * from t1 where cell='111';
第一个语句，where后的值类型是整数（与表cell类型不符）；
第二个语句，where后的值类型是字符串（与表cell类型一致）；

• 测试结果

  
  
  

  列类型与where后值类型不符.png
  
  
  

  列类型与where后值类型相同.png
  
  

  强制类型转换，不能命中索引，需要全表扫描，即3条记录；
  类型相同，命中索引，1条记录；

2. 相join的两个表的字符编码不同，不能命中索引，会导致笛卡尔积的循环计算（nested loop）

create table t2 (
cell varchar(3) primary key
)engine=innodb default charset=latin1;

insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

create table t3 (
cell varchar(3) primary key
)engine=innodb default charset=utf8;

insert into t3(cell) values ('111'),('222'),('333'),('444'),('555'),('666');
t2和t1字符集不同，插入6条测试数据；
t3和t1字符集相同，也插入6条测试数据；

• 测试语句

explain select * from t1,t2 where t1.cell=t2.cell;
explain select * from t1,t3 where t1.cell=t3.cell;
第一个join，连表t1和t2（字符集不同），关联属性是cell；
第一个join，连表t1和t3（字符集相同），关联属性是cell；

• 测试结果

  
  
  

  字符编码不同.png
  
  
  

  字符编码相同.png
  
  

  t1和t2字符集不同，存储空间不同；
  t1和t2相join时，遍历了t1的所有记录3条，t1的每一条记录又要遍历t2的所有记录6条，实际进行了笛卡尔积循环计算(nested loop)，索引无效；
  t1和t3相join时，遍历了t1的所有记录3条，t1的每一条记录使用t3索引，即扫描1行记录；

explain

• type访问类型，即找到所需数据使用的遍历方式，潜在的方式有：
  ALL（Full Table Scan）：全表扫描；
  index：走索引的全表扫描；
  range：命中where子句的范围索引扫描；
  ref/eq_ref：非唯一索引/唯一索引单值扫描；
  const/system：常量扫描；
  NULL：不用访问表；
  ALL最慢，逐步变快，NULL最快。
• Extra字段，对分析与优化SQL有很大的帮助

1. Using where
   Extra为Using where说明，SQL使用了where条件过滤数据
   需要注意的是：
   （1）返回所有记录的SQL，不使用where条件过滤数据，大概率不符合预期，对于这类SQL往往需要进行优化；
   （2）使用了where条件的SQL，并不代表不需要优化，往往需要配合explain结果中的type（连接类型）来综合判断；
   （3）常见的优化方法为，在where过滤属性上添加索引。
2. Using index
   Extra为Using index说明，SQL所需要返回的所有列数据均在一棵索引树上，而无需访问实际的行记录。
   这类SQL语句往往性能较好。
3. Using index condition
   Extra为Using index condition说明，确实命中了索引，但不是所有的列数据都在索引树上，还需要访问实际的行记录。
4. Using filesort
   Extra为Using filesort说明，得到所需结果集，需要对所有记录进行文件排序。
   这类SQL语句性能极差，需要进行优化。
   在一个没有建立索引的列上进行了order by，就会触发filesort，常见的优化方案是，在order by的列上添加索引，避免每次查询都全量排序。
5. Using temporary
   Extra为Using temporary说明，需要建立临时表(temporary table)来暂存中间结果。
   这类SQL语句性能较低，往往也需要进行优化。
   group by和order by同时存在，且作用于不同的字段时，就会建立临时表，以便计算出最终的结果集。
6. Using join buffer (Block Nested Loop)
   Extra为Using join buffer (Block Nested Loop)说明，需要进行嵌套循环计算。
   这类SQL语句性能往往也较低，需要进行优化。
   两个关联表join，关联字段均未建立索引，就会出现这种情况。常见的优化方案是，在关联字段上添加索引，避免每次嵌套循环计算。