MySQL EXPLAIN 完全解读

本贴最后更新于 254 天前,其中的信息可能已经时移世改

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;

结果输出展示:

p1

结果解读

  • id

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

  • select_type

    查询类型,有如下几种取值:

    p2

    p3

  • 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 计算1

  • 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;
      

      结果:

      p4

    • 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 子句中的其他条件去过滤这些数据行。通过这种方式,除非有必要,否则索引信息将可以延迟“下推”读取整个行的数据。例如:

      p5

    • 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
      


  1. 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

    MySQL 是一个关系型数据库管理系统,由瑞典 MySQL AB 公司开发,目前属于 Oracle 公司。MySQL 是最流行的关系型数据库管理系统之一。

    690 引用 • 535 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...

推荐标签 标签

  • 周末

    星期六到星期天晚,实行五天工作制后,指每周的最后两天。再过几年可能就是三天了。

    14 引用 • 297 回帖 • 2 关注
  • Vue.js

    Vue.js(读音 /vju ː/,类似于 view)是一个构建数据驱动的 Web 界面库。Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。

    266 引用 • 665 回帖 • 1 关注
  • 智能合约

    智能合约(Smart contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。智能合约概念于 1994 年由 Nick Szabo 首次提出。

    1 引用 • 11 回帖 • 3 关注
  • CSS

    CSS(Cascading Style Sheet)“层叠样式表”是用于控制网页样式并允许将样式信息与网页内容分离的一种标记性语言。

    198 引用 • 550 回帖
  • Python

    Python 是一种面向对象、直译式电脑编程语言,具有近二十年的发展历史,成熟且稳定。它包含了一组完善而且容易理解的标准库,能够轻松完成很多常见的任务。它的语法简捷和清晰,尽量使用无异义的英语单词,与其它大多数程序设计语言使用大括号不一样,它使用缩进来定义语句块。

    543 引用 • 672 回帖
  • 音乐

    你听到信仰的声音了么?

    60 引用 • 511 回帖
  • LeetCode

    LeetCode(力扣)是一个全球极客挚爱的高质量技术成长平台,想要学习和提升专业能力从这里开始,充足技术干货等你来啃,轻松拿下 Dream Offer!

    209 引用 • 72 回帖
  • Typecho

    Typecho 是一款博客程序,它在 GPLv2 许可证下发行,基于 PHP 构建,可以运行在各种平台上,支持多种数据库(MySQL、PostgreSQL、SQLite)。

    12 引用 • 65 回帖 • 437 关注
  • SendCloud

    SendCloud 由搜狐武汉研发中心孵化的项目,是致力于为开发者提供高质量的触发邮件服务的云端邮件发送平台,为开发者提供便利的 API 接口来调用服务,让邮件准确迅速到达用户收件箱并获得强大的追踪数据。

    2 引用 • 8 回帖 • 483 关注
  • B3log

    B3log 是一个开源组织,名字来源于“Bulletin Board Blog”缩写,目标是将独立博客与论坛结合,形成一种新的网络社区体验,详细请看 B3log 构思。目前 B3log 已经开源了多款产品:SymSoloVditor思源笔记

    1063 引用 • 3453 回帖 • 203 关注
  • 创业

    你比 99% 的人都优秀么?

    84 引用 • 1399 回帖 • 1 关注
  • 微服务

    微服务架构是一种架构模式,它提倡将单一应用划分成一组小的服务。服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在独立的进程中。服务于服务之间才用轻量级的通信机制互相沟通。每个服务都围绕着具体业务构建,能够被独立的部署。

    96 引用 • 155 回帖 • 1 关注
  • uTools

    uTools 是一个极简、插件化、跨平台的现代桌面软件。通过自由选配丰富的插件,打造你得心应手的工具集合。

    6 引用 • 14 回帖 • 2 关注
  • Vditor

    Vditor 是一款浏览器端的 Markdown 编辑器,支持所见即所得、即时渲染(类似 Typora)和分屏预览模式。它使用 TypeScript 实现,支持原生 JavaScript、Vue、React 和 Angular。

    351 引用 • 1813 回帖
  • 反馈

    Communication channel for makers and users.

    123 引用 • 911 回帖 • 245 关注
  • Kafka

    Kafka 是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是现代系统中许多功能的基础。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

    36 引用 • 35 回帖
  • etcd

    etcd 是一个分布式、高可用的 key-value 数据存储,专门用于在分布式系统中保存关键数据。

    5 引用 • 26 回帖 • 529 关注
  • TensorFlow

    TensorFlow 是一个采用数据流图(data flow graphs),用于数值计算的开源软件库。节点(Nodes)在图中表示数学操作,图中的线(edges)则表示在节点间相互联系的多维数据数组,即张量(tensor)。

    20 引用 • 19 回帖
  • JSON

    JSON (JavaScript Object Notation)是一种轻量级的数据交换格式。易于人类阅读和编写。同时也易于机器解析和生成。

    52 引用 • 190 回帖
  • 资讯

    资讯是用户因为及时地获得它并利用它而能够在相对短的时间内给自己带来价值的信息,资讯有时效性和地域性。

    55 引用 • 85 回帖
  • 分享

    有什么新发现就分享给大家吧!

    248 引用 • 1792 回帖
  • Pipe

    Pipe 是一款小而美的开源博客平台。Pipe 有着非常活跃的社区,可将文章作为帖子推送到社区,来自社区的回帖将作为博客评论进行联动(具体细节请浏览 B3log 构思 - 分布式社区网络)。

    这是一种全新的网络社区体验,让热爱记录和分享的你不再感到孤单!

    132 引用 • 1114 回帖 • 125 关注
  • Sublime

    Sublime Text 是一款可以用来写代码、写文章的文本编辑器。支持代码高亮、自动完成,还支持通过插件进行扩展。

    10 引用 • 5 回帖
  • Sillot

    Insights(注意当前设置 master 为默认分支)

    汐洛彖夲肜矩阵(Sillot T☳Converbenk Matrix),致力于服务智慧新彖乄,具有彖乄驱动、极致优雅、开发者友好的特点。其中汐洛绞架(Sillot-Gibbet)基于自思源笔记(siyuan-note),前身是思源笔记汐洛版(更早是思源笔记汐洛分支),是智慧新录乄终端(多端融合,移动端优先)。

    主仓库地址:Hi-Windom/Sillot

    文档地址:sillot.db.sc.cn

    注意事项:

    1. ⚠️ 汐洛仍在早期开发阶段,尚不稳定
    2. ⚠️ 汐洛并非面向普通用户设计,使用前请了解风险
    3. ⚠️ 汐洛绞架基于思源笔记,开发者尽最大努力与思源笔记保持兼容,但无法实现 100% 兼容
    29 引用 • 25 回帖 • 85 关注
  • OpenStack

    OpenStack 是一个云操作系统,通过数据中心可控制大型的计算、存储、网络等资源池。所有的管理通过前端界面管理员就可以完成,同样也可以通过 Web 接口让最终用户部署资源。

    10 引用 • 4 关注
  • 博客

    记录并分享人生的经历。

    273 引用 • 2388 回帖
  • SSL

    SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS 与 SSL 在传输层对网络连接进行加密。

    70 引用 • 193 回帖 • 432 关注