SQL 优化器-能省点力就省点

请思考一个问题，SQL优化器是怎么工作的?

#建表SQL
create table why_index(
    id int unsigned primary key auto_increment comment '自增主键id',
    k1 int unsigned not null default "0" comment '该字段将添加一个索引',
    c1 varchar(32) not null default "" comment '对照字段`另有它用`',
    index idx_k1(k1)
) engine = innodb, character set utf8mb4, comment "探究优化器选择索引";

#插入数据SQL
insert into why_index(k1, c1) values
(5, 'a5'),
(3, 'a3'),
(4, 'a4'),
(2, 'a2'),
(1, 'a1');

以下3条SQL，你是不是和我想的一样

select * from why_index limit 3;
#结果是[{1, 5, a5}, {2, 3, a3}, {3, 4, a4}] 
select c1 from why_index limit 3;
#结果是[a5, a3, a4] 
select k1 from why_index limit 3;
#结果是[1, 2, 3]  ??
#?? 为什么 `select k1 from why_index limit 3` 的结果集不是 [5, 3, 4] 呢?
select id from why_index limit 3;
#你难道会以为结果集会是 [1, 2, 3] ?? 我是这么以为的..

底层数据图例表示，二级索引k1和主键id的叶子节点链表结构:

答案如下：
使用explain查看4条SQL的执行计划得出：
SQL-1 扫描主键id叶子节点链表（取出元组中所有字段）；
SQL-2 扫描主键id叶子节点链表（取出元组中的字段c1）；
SQL-3 扫描索引k1叶子节点链表 并将k1叶子节点索引值作为结果返回（覆盖索引）；
SQL-4 扫描索引k1叶子节点链表 并将k1叶子节点data值即主键id作为结果返回（覆盖索引）；

结论：SQL（存储引擎）将会按照执行计划来读取数据，注：上面的SQL虽都未用到where子句，但是~浅显易懂~又基础） 虽然简单，但愿有趣还有收获

本作品采用《CC 协议》，转载必须注明作者和本文链接