MySQL EXPLAIN 完全解读

EXPLAIN 作为 MySQL 的性能分析神器，读懂其结果是很有必要的，然而我在各种搜索引擎上竟然找不到特别完整的解读。都是只有重点，没有细节（例如 type 的取值不全、Extra 缺乏完整的介绍等）。

所以，我肝了将近一个星期，整理了一下。这应该是全网最全面、最细致的 EXPLAIN 解读文章了，下面是全文。

本文基于 MySQL 8.0 编写，理论支持 MySQL 5.0 及更高版本。

EXPLAIN 使用

explain 可用来分析 SQL 的执行计划。格式如下：

{EXPLAIN | DESCRIBE | DESC}
    tbl_name [col_name | wild]

{EXPLAIN | DESCRIBE | DESC}
    [explain_type]
    {explainable_stmt | FOR CONNECTION connection_id}

{EXPLAIN | DESCRIBE | DESC} ANALYZE select_statement  

explain_type: {
    FORMAT = format_name
}

format_name: {
    TRADITIONAL
  | JSON
  | TREE
}

explainable_stmt: {
    SELECT statement
  | TABLE statement
  | DELETE statement
  | INSERT statement
  | REPLACE statement
  | UPDATE statement
}

示例

EXPLAIN format = TRADITIONAL json SELECT tt.TicketNumber, tt.TimeIn,
               tt.ProjectReference, tt.EstimatedShipDate,
               tt.ActualShipDate, tt.ClientID,
               tt.ServiceCodes, tt.RepetitiveID,
               tt.CurrentProcess, tt.CurrentDPPerson,
               tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
               et_1.COUNTRY, do.CUSTNAME
        FROM tt, et, et AS et_1, do
        WHERE tt.SubmitTime IS NULL
          AND tt.ActualPC = et.EMPLOYID
          AND tt.AssignedPC = et_1.EMPLOYID
          AND tt.ClientID = do.CUSTNMBR;

结果输出展示：

结果解读

id

该语句的唯一标识。如果 explain 的结果包括多个 id 值，则数字越大越先执行；而对于相同 id 的行，则表示从上往下依次执行。
select_type

查询类型，有如下几种取值：
table

表示当前这一行正在访问哪张表，如果 SQL 定义了别名，则展示表的别名
partitions

当前查询匹配记录的分区。对于未分区的表，返回 null
type

连接类型，有如下几种取值，性能从好到坏排序 如下：
- system：该表只有一行（相当于系统表），system 是 const 类型的特例
- const：针对主键或唯一索引的等值查询扫描, 最多只返回一行数据. const 查询速度非常快, 因为它仅仅读取一次即可
- eq_ref：当使用了索引的全部组成部分，并且索引是 PRIMARY KEY 或 UNIQUE NOT NULL 才会使用该类型，性能仅次于 system 及 const。
```
-- 多表关联查询，单行匹配
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;
```
- 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;
```
  最左前缀原则，指的是索引按照最左优先的方式匹配索引。比如创建了一个组合索引(column1, column2, column3)，那么，如果查询条件是：
  - WHERE column1 = 1、WHERE column1= 1 AND column2 = 2、WHERE column1= 1 AND column2 = 2 AND column3 = 3 都可以使用该索引；
  - WHERE column2 = 2、WHERE column2 = 2 AND column3 = 3 就无法匹配该索引。
- fulltext：全文索引
- ref_or_null：该类型类似于 ref，但是 MySQL 会额外搜索哪些行包含了 NULL。这种类型常见于解析子查询
```
SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;
```
- index_merge：此类型表示使用了索引合并优化，表示一个查询里面用到了多个索引
- unique_subquery：该类型和 eq_ref 类似，但是使用了 IN 查询，且子查询是主键或者唯一索引。例如：
```
value IN (SELECT primary_key FROM single_table WHERE some_expr)
```
- index_subquery：和 unique_subquery 类似，只是子查询使用的是非唯一索引
```
value IN (SELECT key_column FROM single_table WHERE some_expr)
```
- range：范围扫描，表示检索了指定范围的行，主要用于有限制的索引扫描。比较常见的范围扫描是带有 BETWEEN 子句或 WHERE 子句里有 >、>=、<、<=、IS NULL、<=>、BETWEEN、LIKE、IN()等操作符。
```
SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);
```
- index：全索引扫描，和 ALL 类似，只不过 index 是全盘扫描了索引的数据。当查询仅使用索引中的一部分列时，可使用此类型。有两种场景会触发：
  - 如果索引是查询的覆盖索引，并且索引查询的数据就可以满足查询中所需的所有数据，则只扫描索引树。此时，explain 的 Extra 列的结果是 Using index。index 通常比 ALL 快，因为索引的大小通常小于表数据。
  - 按索引的顺序来查找数据行，执行了全表扫描。此时，explain 的 Extra 列的结果不会出现 Uses index。
- ALL：全表扫描，性能最差。
possible_keys

展示当前查询可以使用哪些索引，这一列的数据是在优化过程的早期创建的，因此有些索引可能对于后续优化过程是没用的。
key

表示 MySQL 实际选择的索引
key_len

索引使用的字节数。由于存储格式，当字段允许为 NULL 时，key_len 比不允许为空时大 1 字节。

key_len 计算公式：explain 之 key_len 计算¹
ref

表示将哪个字段或常量和 key 列所使用的字段进行比较。

如果 ref 是一个函数，则使用的值是函数的结果。要想查看是哪个函数，可在 EXPLAIN 语句之后紧跟一个 SHOW WARNING 语句。
rows

MySQL 估算会扫描的行数，数值越小越好。
filtered

表示符合查询条件的数据百分比，最大 100。用 rows × filtered 可获得和下一张表连接的行数。例如 rows = 1000，filtered = 50%，则和下一张表连接的行数是 500。

在 MySQL 5.7 之前，想要显示此字段需使用 explain extended 命令；
MySQL.5.7 及更高版本，explain 默认就会展示 filtered
Extra

展示有关本次查询的附加信息，取值如下：
- Child of ‘table’ pushed join@1
  
  此值只会在 NDB Cluster 下出现。
- const row not found
  
  例如查询语句 SELECT … FROM tbl_name，而表是空的
- Deleting all rows
  
  对于 DELETE 语句，某些引擎（例如 MyISAM）支持以一种简单而快速的方式删除所有的数据，如果使用了这种优化，则显示此值
- Distinct
  
  查找 distinct 值，当找到第一个匹配的行后，将停止为当前行组合搜索更多行
- FirstMatch(tbl_name)
  
  当前使用了半连接 FirstMatch 策略,详见 https://mariadb.com/kb/en/firstmatch-strategy/，翻译 https://www.cnblogs.com/abclife/p/10895624.html
- Full scan on NULL key
  
  子查询中的一种优化方式，在无法通过索引访问 null 值的时候使用
- Impossible HAVING
  
  HAVING 子句始终为 false，不会命中任何行
- Impossible WHERE
  
  WHERE 子句始终为 false，不会命中任何行
- Impossible WHERE noticed after reading const tables
  
  MySQL 已经读取了所有 const（或 system）表，并发现 WHERE 子句始终为 false
- LooseScan(m…n)
  
  当前使用了半连接 LooseScan 策略，详见 https://mariadb.com/kb/en/loosescan-strategy/，翻译 http://www.javacoder.cn/?p=39
- No matching min/max row
  
  没有任何能满足例如 SELECT MIN(…) FROM … WHERE condition 中的 condition 的行
- no matching row in const table
  
  对于关联查询，存在一个空表，或者没有行能够满足唯一索引条件
- No matching rows after partition pruning
  
  对于 DELETE 或 UPDATE 语句，优化器在 partition pruning（分区修剪）之后，找不到要 delete 或 update 的内容
- No tables used
  
  当此查询没有 FROM 子句或拥有 FROM DUAL 子句时出现。例如：explain select 1
- Not exists
  
  MySQL 能对 LEFT JOIN 优化，在找到符合 LEFT JOIN 的行后，不会为上一行组合中检查此表中的更多行。例如：
```
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;
```
  假设 t2.id 定义成了 NOT NULL ，此时，MySQL 会扫描 t1，并使用 t1.id 的值查找 t2 中的行。如果 MySQL 在 t2 中找到一个匹配的行，它会知道 t2.id 永远不会为 NULL，并且不会扫描 t2 中具有相同 id 值的其余行。也就是说，对于 t1 中的每一行，MySQL 只需要在 t2 中只执行一次查找，而不考虑在 t2 中实际匹配的行数。
  
  在 MySQL 8.0.17 及更高版本中，如果出现此提示，还可表示形如 NOT IN (subquery) 或 NOT EXISTS (subquery) 的 WHERE 条件已经在内部转换为反连接。这将删除子查询并将其表放入最顶层的查询计划中，从而改进查询的开销。通过合并半连接和反联接，优化器可以更加自由地对执行计划中的表重新排序，在某些情况下，可让查询提速。你可以通过在 EXPLAIN 语句后紧跟一个 SHOW WARNING 语句，并分析结果中的 Message 列，从而查看何时对该查询执行了反联接转换。
  
  两表关联只返回主表的数据，并且只返回主表与子表没关联上的数据，这种链接就叫反链接
- Plan isn’t ready yet
  
  使用了 EXPLAIN FOR CONNECTION，当优化器尚未完成为在指定连接中为执行的语句创建执行计划时，就会出现此值。
- Range checked for each record (index map: N)
  
  MySQL 没有找到合适的索引去使用，但是去检查是否可以使用 range 或 index_merge 来检索行时，会出现此提示。index map N 索引的编号从 1 开始，按照与表的 SHOW INDEX 所示相同的顺序。索引映射值 N 是指示哪些索引是候选的位掩码值。例如 0x19（二进制 11001）的值意味着将考虑索引 1、4 和 5。
  
  示例：下面例子中，name 是 varchar 类型，但是条件给出整数型，涉及到隐式转换。
  图中 t2 也没有用到索引，是因为查询之前我将 t2 中 name 字段排序规则改为 utf8_bin 导致的链接字段排序规则不匹配。
```
explain select a.* from t1 a left  join t2 b
on t1.name = t2.name
where t2.name = 2;
```
  结果：
- Recursive
  
  出现了递归查询。详见：https://dev.mysql.com/doc/refman/8.0/en/with.html
- Rematerialize
  
  用得很少，使用类似如下 SQL 时，会展示 Rematerialize
```
SELECT
  ...
FROM
  t,
  LATERAL (derived table that refers to t) AS dt
```
- Scanned N databases
  
  表示在处理 INFORMATION_SCHEMA 表的查询时，扫描了几个目录，N 的取值可以是 0，1 或者 all。详见 https://dev.mysql.com/doc/refman/8.0/en/information-schema-optimization.html
- Select tables optimized away
  
  优化器确定：① 最多返回 1 行；② 要产生该行的数据，要读取一组确定的行，时会出现此提示。一般在用某些聚合函数访问存在索引的某个字段时，优化器会通过索引直接一次定位到所需要的数据行完成整个查询时展示，例如下面这条 SQL。
```
explain
select min(id)
from t1;
```
- Skip_open_table， Open_frm_only， Open_full_table
  
  这些值表示适用于 INFORMATION_SCHEMA 表查询的文件打开优化；
- Skip_open_table：无需打开表文件，信息已经通过扫描数据字典获得
- Open_frm_only：仅需要读取数据字典以获取表信息
- Open_full_table：未优化的信息查找。表信息必须从数据字典以及表文件中读取
- Start temporary, End temporary
  
  表示临时表使用 Duplicate Weedout 策略，详见 https://mariadb.com/kb/en/duplicateweedout-strategy/
- unique row not found
  
  对于形如 SELECT … FROM tbl_name 的查询，但没有行能够满足唯一索引或主键查询的条件
- Using filesort
  
  当 Query 中包含 ORDER BY 操作，而且无法利用索引完成排序操作的时候，MySQL Query Optimizer 不得不选择相应的排序算法来实现。数据较少时从内存排序，否则从磁盘排序。Explain 不会显示的告诉客户端用哪种排序。官方解释：“MySQL 需要额外的一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配 WHERE 子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行”
- Using index
  
  仅使用索引树中的信息从表中检索列信息，而不必进行其他查找以读取实际行。当查询仅使用属于单个索引的列时，可以使用此策略。例如：
  
  explan SELECT id FROM t
- Using index condition
  
  表示先按条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用 WHERE 子句中的其他条件去过滤这些数据行。通过这种方式，除非有必要，否则索引信息将可以延迟“下推”读取整个行的数据。例如：
- Using index for group-by
  
  数据访问和 Using index 一样，所需数据只须要读取索引，当 Query 中使用 GROUP BY 或 DISTINCT 子句时，如果分组字段也在索引中，Extra 中的信息就会是 Using index for group-by。例如
```
-- name字段有索引
explain SELECT name FROM t1 group by name
```
- Using index for skip scan
  
  表示使用了 Skip Scan。
- Using temporary
  
  为了解决该查询，MySQL 需要创建一个临时表来保存结果。如果查询包含不同列的 GROUP BY 和 ORDER BY 子句，通常会发生这种情况。
```
-- name无索引
explain SELECT name FROM t1 group by name
```
- Using where
  
  如果我们不是读取表的所有数据，或者不是仅仅通过索引就可以获取所有需要的数据，则会出现 using where 信息
```
explain SELECT * FROM t1 where id > 5
```
  ‍

‍

explain 之 key_len 计算

通常在优化 SQL 查询的时候，我们都会使用 explain 分析 SQL 执行计划，通常来说当用到组合索引的时候我们如何判断索引完全用上呢？当然高手看看表结构及 SQL 语句就知道到底用到了几个字段，对于不熟悉的同学呢？我们还是可以看看 key_len 的长度，当然这个计算还是有点复杂的，不过在你看过我这篇博客以后，相信你肯定会计算的，这难不倒聪明的你。

废话不多说了，我们直接上例子。表结构如下。

mysql [localhost] {msandbox} (yayun) > show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` char(20) NOT NULL DEFAULT '',
  `name1` char(20) DEFAULT NULL,
  `name3` varchar(20) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql [localhost] {msandbox} (yayun) >

上面的表结构非常简单，有个主键索引，也就是 id 字段，还有一个辅助索引，也就是 name 字段，下面我们执行一条 SQL，并分析一下执行计划，看看到底 key_len 如何计算的。
表中就 3 条记录：

mysql [localhost] {msandbox} (yayun) > select * from t1;
+----+-------+-------+-----------+
| id | name  | name1 | name3     |
+----+-------+-------+-----------+
|  1 | atlas | yayun | dengyayun |
|  2 | alex  | talex | jalex     |
|  3 | je    | jetom | tomje     |
+----+-------+-------+-----------+
3 rows in set (0.00 sec)

mysql [localhost] {msandbox} (yayun) >

下面进行 explain 进行查看 key_len 的长度

mysql [localhost] {msandbox} (yayun) > explain select * from t1 where name='atlas';
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra                 |
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------+
|  1 | SIMPLE      | t1    | ref  | name          | name | 60      | const |    1 | Using index condition |
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------+
1 row in set (0.03 sec)

mysql [localhost] {msandbox} (yayun) >

可以看到 key_len 的长度是 60，那么这个 60 是如何计算出来的。当然如果是单列索引我们不用去计算，因为没有意义，如果是组合索引，那么知道这里的长度就是非常有意义的，我们先简单来看看这个单列索引的 key_len 等于 60 是如何计算的。
还记得前面我的表结构里面 name 字段的定义么？

name char(20) NOT NULL DEFAULT '',我定义了 char（20），且非空。

好，现在我们来计算一下，首先我的表用的 utf8 字符集，那么大家都知道 utf8 字符集占用 3 个字节，那么我又定义 char（20），知道结果了么？聪明的你一定知道了。

key_len=20*3=60

计算简单吧，这个情况确实简单，还有复杂的情况呢，嘿嘿。

我们下面继续看下一条 SQL，我们把 name 这个字段的索引去掉，添加一个联合索引，key（name，name1）

mysql [localhost] {msandbox} (yayun) > alter table t1 drop key name;
Query OK, 0 rows affected (0.15 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql [localhost] {msandbox} (yayun) > alter table t1 add key idx_key_name_name1 (name,name1);
Query OK, 0 rows affected (0.29 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql [localhost] {msandbox} (yayun) >

我们再来进行一条查询：

mysql [localhost] {msandbox} (yayun) > explain select * from t1 where name='atlas';
+----+-------------+-------+------+--------------------+--------------------+---------+-------+------+-----------------------+
| id | select_type | table | type | possible_keys      | key                | key_len | ref   | rows | Extra                 |
+----+-------------+-------+------+--------------------+--------------------+---------+-------+------+-----------------------+
|  1 | SIMPLE      | t1    | ref  | idx_key_name_name1 | idx_key_name_name1 | 60      | const |    1 | Using index condition |
+----+-------------+-------+------+--------------------+--------------------+---------+-------+------+-----------------------+
1 row in set (0.00 sec)

mysql [localhost] {msandbox} (yayun) > explain select * from t1 where name='atlas' and name1='yayun';
+----+-------------+-------+------+--------------------+--------------------+---------+-------------+------+-----------------------+
| id | select_type | table | type | possible_keys      | key                | key_len | ref         | rows | Extra                 |
+----+-------------+-------+------+--------------------+--------------------+---------+-------------+------+-----------------------+
|  1 | SIMPLE      | t1    | ref  | idx_key_name_name1 | idx_key_name_name1 | 121     | const,const |    1 | Using index condition |
+----+-------------+-------+------+--------------------+--------------------+---------+-------------+------+-----------------------+
1 row in set (0.04 sec)

mysql [localhost] {msandbox} (yayun) >

看到第一条查询和第二条的查询的执行计划有什么不同了么？没错，key_len 及 ref 列不一样了。why？以及为什么第二条 SQL 语句的 key_len 为 121，这个是如何计算的？嘿嘿，如果还用上面的计算方法你肯定计算不出来的。让我来告诉你。还记得 name1 字段的定义么？
name1 char(20) DEFAULT NULL,

可以发现 name1 字段的定义为 DEFAULT NULL，其他没变化。所以 MySQL 需要 1 个字节来标识 NULL，

所以第二条 SQL 的 key_len=20 * 3 + (20 * 3 +1)=121，通过计算，我们知道 2 个字段的索引完全用上了。

下面我们再继续看看其他的情况，给表添加一个字段，并添加一个联合索引，我们进行一个范围的查询。

mysql [localhost] {msandbox} (yayun) > alter table t1 add add_time timestamp;
Query OK, 0 rows affected (1.44 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql [localhost] {msandbox} (yayun) > alter table t1 add key idx_key_add_time_name3 (add_time,name3);      
Query OK, 0 rows affected (0.19 sec)
Records: 0  Duplicates: 0  Warnings: 0

现在的表结构这样了。

mysql [localhost] {msandbox} (yayun) > show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` char(20) NOT NULL DEFAULT '',
  `name1` char(20) DEFAULT NULL,
  `name3` varchar(20) NOT NULL DEFAULT '',
  `add_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_key_name_name1` (`name`,`name1`),
  KEY `idx_key_add_time_name3` (`add_time`,`name3`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
1 row in set (0.01 sec)

mysql [localhost] {msandbox} (yayun) >

看 SQL，废话不多说。

mysql [localhost] {msandbox} (yayun) > explain select * from t1 where add_time >='2014-09-10 02:36:46' and add_time <='2014-09-11 02:36:46' group by name3 order by null;
+----+-------------+-------+-------+------------------------+------------------------+---------+------+------+----------------------------------------+
| id | select_type | table | type  | possible_keys          | key                    | key_len | ref  | rows | Extra                                  |
+----+-------------+-------+-------+------------------------+------------------------+---------+------+------+----------------------------------------+
|  1 | SIMPLE      | t1    | range | idx_key_add_time_name3 | idx_key_add_time_name3 | 4       | NULL |    2 | Using index condition; Using temporary |
+----+-------------+-------+-------+------------------------+------------------------+---------+------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql [localhost] {msandbox} (yayun) >

可以看见用到了我创建的联合索引 idx_key_add_time_name3，但是真的完全用到了么。其实一眼就知道没有用到，因为前面是一个范围查询，后面字段的索引就用不到，如果我这里不 order by null，还会看到 Using filesort。但是我还是想说说 key_len 是如何计算的，大家都很清楚 timestamp 占用 4 字节吧。那么答案显而易见，看见 key_len 是 4，说明只用到了联合索引 idx_key_add_time_name3 中的 add_time 字段。

我们再来看一种情况，是 char 字段和 varchar 字段组成的一个联合索引。

mysql [localhost] {msandbox} (yayun) > alter table t1 add key idx_key_name1_name3 (name1,name3);
Query OK, 0 rows affected (0.27 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql [localhost] {msandbox} (yayun) >

SQL 如下：

mysql [localhost] {msandbox} (yayun) > explain select * from t1 where name1='yayun' and name3='dengyayun';
+----+-------------+-------+------+---------------------+---------------------+---------+-------------+------+-----------------------+
| id | select_type | table | type | possible_keys       | key                 | key_len | ref         | rows | Extra                 |
+----+-------------+-------+------+---------------------+---------------------+---------+-------------+------+-----------------------+
|  1 | SIMPLE      | t1    | ref  | idx_key_name1_name3 | idx_key_name1_name3 | 123     | const,const |    1 | Using index condition |
+----+-------------+-------+------+---------------------+---------------------+---------+-------------+------+-----------------------+
1 row in set (0.00 sec)

mysql [localhost] {msandbox} (yayun) >

可以看见 key_len 的长度是 123。那么索引完全用到了么？当然有点索引常识都知道完全用到了。我这里只是为了告诉大家 key_len 到底如何计算的。
name3 varchar(20) NOT NULL DEFAULT ''

name1 char(20) DEFAULT NULL,

上面是 2 个字段的定义，1 个允许 NULL，一个 NOT NULL，一个 char，一个 varchar

所以 key_len=（20*3 + 1）+（20 * 3 + 2）= 123

由此来判断这个组合索引已经完全使用。相信有同学会问了，+1 是干嘛，+2 是干嘛。这就告诉大家，+1 是因为 MySQL 需要 1 个字节标识 NULL，+2 是因为 name3 字段为 varchar，是变长字段需要 +2。

写到这里相信大家都有一个基本认识了吧。好了，多的不说了，公式放出来给大家，自己套用公式，多做几次测试就明白啦。

key_len 的长度计算公式：

varchr(10)变长字段且允许NULL    =  10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)
varchr(10)变长字段且不允许NULL  =  10 *( character set：utf8=3,gbk=2,latin1=1)+2(变长字段)

char(10)固定字段且允许NULL      =  10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)
char(10)固定字段且不允许NULL    =  10 * ( character set：utf8=3,gbk=2,latin1=1)

‍

‍ ↩

MySQL EXPLAIN 完全解读

explain 之 key_len 计算

相关帖子

堡塔面板使用 Docker 部署 MySQL 多实例

MYSQL

MySQL 间隙锁

MySQL 设置自动断开时间

在 Debian 11 x64 上安装 MySQL 8.0

Mac 使用 Docker-compose 安装部署 Clickhouse 的经验和问题

Mysql 脚本常用整理

欢迎来到这里！

近期热议

推荐标签标签

最新标签

MySQL EXPLAIN 完全解读

explain 之 key_len 计算

相关帖子

堡塔面板使用 Docker 部署 MySQL 多实例

MYSQL

MySQL 间隙锁

MySQL 设置自动断开时间

在 Debian 11 x64 上安装 MySQL 8.0

Mac 使用 Docker-compose 安装部署 Clickhouse 的经验和问题

Mysql 脚本常用整理

欢迎来到这里！

近期热议

推荐标签 标签

最新标签

推荐标签标签