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的叶子节点链表结构:

SQL 优化器-能走索引为啥不走捏(真香)


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

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

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!