最近在看索引没有命中的情况，在自己实际操作后还是发现跟网上博客千篇一律的结果有一些不同，网上博客讲的不够细，情况不够全面，因此自己动手实操了下整理了下结论。除了一些小表不适用，大表超过30%不使用无法测试，我从聚簇索引以及二级索引概念入手，更加具体的体会了不同type的原因。

最左前缀在WHERE内无所谓先后，但是WHERE一定先于ORDER BY，只要WHERE+ORDER BY加起来满足最左前缀就行。

  1. index(索引全扫描,只用到聚簇索引或二级索引)：
    结果列只用到索引内，条件列也是索引内(不是范围查询)但没满足最左前缀。上述情况即使在WHERE column+1=0亦或者DATE(column)都是一样的结果,不会破坏使之无法使用索引。
  2. ref(只用到二级索引)：
    结果列无所谓，条件列是索引以内(不是范围查询)且满足最左前缀，上述情况在WHERE column+1=0亦或者DATE(column)会破坏使之无法使用索引，因为破坏了最左前缀条件。

破坏索引的情况：运算，内置函数，is null(is not null会走),like ‘%'(注意通配符在前),not in,in

  1. range(索引范围，只用到聚簇索引[主键]或二级索引[唯一索引])：
    结果列无所谓，条件列是主键列或唯一索引以及覆盖索引全使用。
    =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE, or IN()

  2. const
    const 只用主键或唯一索引作为条件且只是用到=或<=>

总结：

可以理解为苛刻的条件下，会相应给与一定的补偿措施。

index： 发生在从结果列可知possible_keys但是条件列被破坏或者不满足最左前缀。(普通索引或主键或唯一索引)

ref： 发生在满足最左前缀且不能被破坏。(普通索引)

const： 发生在主键或者唯一索引。(主键或者唯一索引)

range： 发生在主键或者唯一索引或** 完全 **满足最左前缀 且 条件列不被破坏。(主键或者唯一索引或普通索引全使用)

index：
结果列和条件列都是同个索引内，就等于已经告知了存储引擎我要用什么索引，所以放松对条件列要求(你怎么column+1=1,DATE(column)都没影响)(奖励)，因为只需要在二级索引查询就可以满足条件，

ref：：
因为条件列是非常苛刻的要求满足最左前缀，因此在二级索引是可以定位的，不用索引全扫描，因此在找到数据后回聚簇索引拿其他列也无所谓(奖励)。

range:
因为要求是主键或者唯一索引或者索引完全满足！注意是完全满足！因此也对结果列放松要求，但失去的就是对条件列特别的敏感，跟ref一样。

以下是官网的type解释

EXPLAIN Join Types

type:性能排序 从上到下越来越差

1. system

The table has only one row (= system table). This is a special case of the const join type.

2. const

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;

The table has at most one matching row, which is read at the start of the query. Because there is only one row, values from the column in this row can be regarded as constants by the rest of the optimizer. const tables are very fast because they are read only once.

3. eq_ref

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;

One row is read from this table for each combination of rows from the previous tables. Other than the system and const types, this is the best possible join type. It is used when all parts of an index are used by the join and the index is a PRIMARY KEY or UNIQUE NOT NULL index.

eq_ref can be used for indexed columns that are compared using the = operator. The comparison value can be a constant or an expression that uses columns from tables that are read before this table.

4.ref

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;

All rows with matching index values are read from this table for each combination of rows from the previous tables. ref is used if the join uses only a leftmost prefix of the key or if the key is not a PRIMARY KEY or UNIQUE index (in other words, if the join cannot select a single row based on the key value). If the key that is used matches only a few rows, this is a good join type.
ref can be used for indexed columns that are compared using the = or <=> operator.

5.fulltext

The join is performed using a FULLTEXT index.

6.ref_or_null

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

This join type is like ref, but with the addition that MySQL does an extra search for rows that contain NULL values. This join type optimization is used most often in resolving subqueries.

7.index_merge

This join type indicates that the Index Merge optimization is used. In this case, the key column in the output row contains a list of indexes used, and key_len contains a list of the longest key parts for the indexes used.

8.unique_subquery

This type replaces eq_ref for some IN subqueries of the following form:

value IN (SELECT primary_key FROM single_table WHERE some_expr)```
unique_subquery is just an index lookup function that replaces the subquery completely for better efficiency.

## 9.index_subquery

This join type is similar to unique_subquery. It replaces IN subqueries, but it works for nonunique indexes in subqueries of the following form:
```SQL
value IN (SELECT key_column FROM single_table WHERE some_expr)```

value IN (SELECT key_column FROM single_table WHERE some_expr)

## 10.range

Only rows that are in a given range are retrieved, using an index to select the rows. The key column in the output row indicates which index is used. The key_len contains the longest key part that was used. The ref column is NULL for this type.
```SQL
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);

range can be used when a key column is compared to a constant using any of the =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE, or IN() operators:

11.index

The index join type is the same as ALL, except that the index tree is scanned. This occurs two ways:

  • If the index is a covering index for the queries and can be used to satisfy all data required from the table, only the index tree is scanned. In this case, the Extra column says Using index. An index-only scan usually is faster than ALL because the size of the index usually is smaller than the table data.

  • A full table scan is performed using reads from the index to look up data rows in index order. Uses index does not appear in the Extra column.

MySQL can use this join type when the query uses only columns that are part of a single index.

12.ALL

A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that enable row retrieval from the table based on constant values or column values from earlier tables.

KAI Mysql
关于Mysql隔离级别
20190303头条后台一面