MySQL 索引分析

MySQL复合唯一索引分析

---

关于复合唯一索引（unique key 或 unique index），网上搜索不少人说：”这种索引起到的关键作用是约束，查询时性能上没有得到提高或者查询时根本没有走索引列“。也有人说：“查询时使用到了索引和普通索引一样“。那么问题到底是怎样的呢？

测试准备工作

准备建表语句，插入数据等工作：

-- 建表（注：a,b是复合唯一索引）

create table test0(id bigint not null primary key auto_increment, a varchar(10) not null, b varchar
(10) not null, unique index(a, b))engine=innodb charset=utf8 auto_increment=1;



-- 插入数据

insert into test0(a, b)values('china', 'chinese');

insert into test0(a, b)values('japan', 'japanese');

insert into test0(a, b)values('germany', 'german');

insert into test0(a, b)values('korea', 'korea');

insert into test0(a, b)values('france', 'frence');

insert into test0(a, b)values('australia', 'australia');

insert into test0(a, b)values('america', 'american');

insert into test0(a, b)values('brazil', 'brazil');



-- 执行计划一（查询存在纪录）

explain select * from test0 where a='france' and b='frence';

-- 执行计划二（查询不存在纪录）

explain select * from test0 where a='france' and b='america';

执行计划一：

执行计划二：

综上可以看出：
执行计划一，查询条件匹配时命中所有的索引；
执行计划二，查询条件不匹配时没有命中索引，并返回一条Extra”Impossible WHERE noticed after reading const tables”

那么到底这两次查询有什么不同呢？
MySQL关于这种索引的执行计划以及优化方案是什么？
我不得不把官方的Doc阅读一遍，关键点总结如下：

Explain join types 执行计划”type”列表，从执行性能最好到最坏：
1. system
表中只有一行数据（=system table）。这是常数连接类型的特例。
2. const
在查询开始时读取表时仅有一行可以匹配的数据。因为仅匹配到一行数据，所以值列可以被认为是常数级优化。常数表查询非常快因为它们只读取一次就能命中。
常数类型仅仅在匹配”PRIMARY KEY”或者”UNIQUE INDEX”所有的列值时才会被使用。
下面的查询，表被当成常数表执行：

    -- query 1

    SELECT * FROM tbl_name WHERE primary_key=1;

    SELECT * FROM tbl_name

          WHERE primary_key_part1=1 AND primary_key_part2=2;

1. ref
   所有带索引值匹配的行都从这张表读取各种组合的行从之前的表读取。如果连接使用key的只是最左前缀，或者key不是PRIMARY KEY和UNIQUE index使用ref(换句话说，如果连接跟进key值没有查询单行数据)。如果这个key值使用时匹配了仅仅少数的行，这就是一个比较好的类型。
   ref 可以用在索引列，条件匹配时使用”=” 或者 “<=>”操作。下面的示例，MySQL 能够使用ref连接处理 ref_table:

    SELECT * FROM ref_table WHERE key_column=expr;



    SELECT * FROM ref_table,other_table

      WHERE ref_table.key_column=other_table.column;



    SELECT * FROM ref_table,other_table

      WHERE ref_table.key_column_part1=other_table.column

      AND ref_table.key_column_part2=1;

1. ref_or_null
   这种连接有点类似于ref, 但是查询行包含NULL值时，MySQL会作额外的查询。这种连接类型的优化最经常在解决子查询的时候使用。下面的例子，MySQL会使用ref_or_nulll连接处理ref_table:

SELECT * FROM ref_table
      WHERE key_column=expr OR key_column IS NULL;

参见 8.2.1.6, “IS NULL 优化”.

1. index_merge
   这种连接类型说明已经启用索引合并优化。这种场景下，输出行中的key列包含用于索引的列表，并且key_len显示索引使用的最长key parts。更多信息参见“索引合并优化”。

   1. range
      只有当行根据给定范围检索到时，使用一个索引查询这些行。输出行的key列表明使用哪个索引。key_len列显示使用最长的key part。这种连接ref列为NULL。
      当key列和一个常量使用”=”, “<>”, “>”, “>=”, “<”, “<=”, IS NULL, “<=>”, BETWEEN, 或者IN()比较时使用range连接:

    SELECT * FROM tbl_name WHERE key_column = 10;



    SELECT * FROM tbl_name WHERE key_column BETWEEN 10 and 20;


    SELECT * FROM tbl_name WHERE key_column IN (10,20,30);



    SELECT * FROM tbl_name WHERE key_part1 = 10 

    AND key_part2 IN (10,20,30);

1. index
   索引连接类型和ALL一样，除了扫描索引树。两种执行方式:
   如果索引在查询里是一个覆盖性的索引，并且能够查询表中所有满足的数据，只有索引树被扫描。这种场景下，Extra列会显示”Using index”。通常只走索引扫描比全表扫描要快很多，因为索引的数量通常比表中的数据量要少很多。全表扫描优化方案是通过读取索引并按照索引顺序检索数据。使用索引不会在Etra列显示。列使用单一索引时，MySQL使用这种连接类型。

   1. ALL
      全表扫描。通常，应该通过添加索引避免全表扫描。

EXPLAIN Extra Information

The Extra column of EXPLAIN output contains additional information about how MySQL resolves the query. The following list explains the values that can appear in this column. If you want to make your queries as fast as possible, look out for Extra values of Using filesort and Using temporary.

1. Child of 'table' pushed join@1


This table is referenced as the child of table in a join that can be pushed down to the NDB kernel. Applies only in MySQL Cluster NDB 7.2 and later, when pushed-down joins are enabled. See the description of the ndb_join_pushdown server system variable for more information and examples.

2. const row not found



For a query such as SELECT ... FROM tbl_name, the table was empty.


3. Distinct



MySQL is looking for distinct values, so it stops searching for more rows for the current row combination after it has found the first matching row.



4. Full scan on NULL key



This occurs for subquery optimization as a fallback strategy when the optimizer cannot use an index-lookup access method.



5. Impossible HAVING



The HAVING clause is always false and cannot select any rows.



6. Impossible WHERE



The WHERE clause is always false and cannot select any rows.



Impossible WHERE noticed after reading const tables



MySQL has read all const (and system) tables and notice that the WHERE clause is always false.

---