02.你猜MySQL哪种索引快？

猜想

        MySQL哪种索引快？聚簇索引 or 非聚簇索引？

试验用表

# 这是一个普通的表小t
CREATE TABLE `t` (
  `id` int(10) NOT NULL COMMENT '大家好，我是主键',
  `a` int(11) DEFAULT NULL COMMENT '大家好，我是字段a，我是一个普通索引',
  `b` int(11) DEFAULT NULL COMMENT '我是一个字段，我没有索引',
  PRIMARY KEY (`id`),
  KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='大家好，我是表`t`'

起因

        在某个风和日丽的下午，大家伙正在沟通业务的时候，引发了一场“辩论”：主键查询会比普通索引查询快吗？

  • 正方：以primary key为条件查询快
  • 反方：效率一样

浅谈索引

        MySQL的索引主要两类，聚簇索引（也叫主键索引、聚集索引）和非聚簇索引（也叫非聚集索引、二级索引、普通索引）。目前MySQL innoDB引擎的索引，主要使用B+树结构，B+树的深度低，叶子节点多，可以有效减少磁盘IO，提升性能。

MySQL的索引结构

        MySQL中每张表的数据，也以B+树的结构保存。同为B+树结构，它与索引的区别是：叶子节点保存的是主键 + 数据，而普通索引保存的是索引值 + 主键，如下图所示。

主键索引数据结构（下图）

image.png

普通索引（下图）

image.png

查询与回表

        那么MySQL查询是如何工作的呢？我想聪明的你已经知道了答案。
        如果我们通过主键查询（比如下面SQL语句），那么innoDB引擎会在保存聚簇索引的这颗B+树中，寻找id = 4的节点，然后通过指针直接获取行数据。

# 根据聚集索引查询数据，一枪头
select * from t where id = 4;

        如果我们通过普通查询（比如下面SQL语句），那么innoDB引擎会在保存普通索引的这颗B+树中，寻找a = 'd'的节点，然后在叶子节点中获取到主键值，再通过主键去查询真实数据，这个过程就叫做回表，显然它比通过聚簇索引去查询，多一步。

# 根据普通索引查询数据，回表一次
select * from t where a = 'd';

        这里有个小知识点，如果我们只需要查询a字段的值，那么普通索引的叶子节点已经包含了结果，就不需要回表了。学名叫做——索引覆盖。

实操

        鉴于前排的理论知识，我们来进行一番实操，步骤如下：

  1. 环境：本机docker mysql:5.6.47
  2. 版本：MySQL 5.6.47
  3. init table
  4. init data
  5. have a try
# step 1 init table
CREATE TABLE `t` (
  `id` int(10) NOT NULL COMMENT '你好，我是主键',
  `a` int(11) DEFAULT NULL COMMENT '大家好，我是字段a，我是一个普通索引',
  `b` int(11) DEFAULT NULL COMMENT '我是一个字段，我没有索引',
  PRIMARY KEY (`id`),
  KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='大家好，我是表`t`'

# step 2 init data
# 插入100w数据
DROP PROCEDURE if exists idata;
delimiter ;;
create procedure idata()
begin
  declare i int;
  set i=1;
  while(i<=100000)do
    insert into t values(i, i, i);
    set i=i+1;
  end while;
end;;
delimiter ;
call idata();


# step 3 test
语句1：select * from t where id < 100000; -- 0.10s
语句2：select * from t where  a < 100000; -- 0.30s

        结果体现出，主键索引更快，而且执行速度差距有点大，我们来看看执行计划。

mysql> explain select * from t where id < 100000;
+----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
| 1  | SIMPLE      | t     | range | PRIMARY       | PRIMARY | 4       | NULL | 200664 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+------+--------+-------------+
1 rows in set (0.02 sec)

mysql> explain select * from t where  a < 100000;
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+
| 1  | SIMPLE      | t     | ALL  | a             | NULL | NULL    | NULL | 998222 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+--------+-------------+
1 rows in set (0.02 sec)

        通过执行计划发现，字段a竟然没有命中索引，执行了全表扫描！
        ==出现这种情况，简单来说，是由于优化器判定扫描行数过多，而且通过索引a查询我们想要的数据，每次都需要通过再次查询主键索引，代价过高，所以放弃使用索引a。==
        那么我们可以强制语句走索引a，再试试查询效果。显然这次使用到了索引。

mysql> explain select * from t force index(a) where  a < 100000;
+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra                 |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------+
| 1  | SIMPLE      | t     | range | a             | a    | 5       | NULL | 205002 | Using index condition |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------+
1 rows in set (0.09 sec)

        再来执行一遍试试看，果然，执行效率上来说：主键索引 > 普通索引 > 全表扫描，附上分析细节，重点关注Sending data。

select * from t where id < 100000;  -- 0.10s
select * from t where  a < 100000;  -- 0.25s
select * from t force index(a) where  a < 100000;   -- 0.13s



mysql> show profiles;
+----------+------------+--------------------------------------------------+
| Query_ID | Duration   | Query                                            |
+----------+------------+--------------------------------------------------+
| 1        | 0.00049450 | set profiling = 1                                |
| 2        | 0.09794425 | select * from t where id < 100000                |
| 3        | 0.25010650 | select * from t where a < 100000                 |
| 4        | 0.12352975 | select * from t force index(a) where  a < 100000 |
+----------+------------+--------------------------------------------------+
4 rows in set (0.02 sec)


mysql> show profile for query 2;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000086 |
| checking permissions | 0.000013 |
| Opening tables       | 0.000077 |
| init                 | 0.000042 |
| System lock          | 0.000042 |
| optimizing           | 0.000028 |
| statistics           | 0.000109 |
| preparing            | 0.000035 |
| executing            | 0.000017 |
| Sending data         | 0.097321 |
| end                  | 0.000079 |
| query end            | 0.000015 |
| closing tables       | 0.000018 |
| freeing items        | 0.000042 |
| cleaning up          | 0.000021 |
+----------------------+----------+
15 rows in set (0.05 sec)

mysql> show profile for query 3;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000121 |
| checking permissions | 0.000019 |
| Opening tables       | 0.000037 |
| init                 | 0.000030 |
| System lock          | 0.000027 |
| optimizing           | 0.000019 |
| statistics           | 0.000056 |
| preparing            | 0.000022 |
| executing            | 0.000014 |
| Sending data         | 0.249550 |
| end                  | 0.000027 |
| query end            | 0.000015 |
| closing tables       | 0.000023 |
| freeing items        | 0.000115 |
| cleaning up          | 0.000034 |
+----------------------+----------+
15 rows in set (0.05 sec)

mysql> show profile for query 4;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000072 |
| checking permissions | 0.000017 |
| Opening tables       | 0.000037 |
| init                 | 0.000029 |
| System lock          | 0.000028 |
| optimizing           | 0.000019 |
| statistics           | 0.000075 |
| preparing            | 0.000023 |
| executing            | 0.000014 |
| Sending data         | 0.123024 |
| end                  | 0.000027 |
| query end            | 0.000012 |
| closing tables       | 0.000017 |
| freeing items        | 0.000052 |
| cleaning up          | 0.000085 |
+----------------------+----------+
15 rows in set (0.01 sec)

        经过以上分析，开始时的“辩论”，我想你心中已有答案。

完

 
 
 

翻车

        其实到这里，故事应该已经结束了，本着熟能生巧的原则，我去测试服务器上再实操了一遍，却出现了意想不到的结果。

环境

1. 环境：阿里云RDS
2. 版本：MySQL 5.6.16-log

现象

语句1：select * from t where id < 100000; -- 0.50s
语句2：select * from t where  a < 100000; -- 0.51s
语句3：select * from t force index (a) where  a < 100000; -- 0.42s
  1. 全表扫描和主键查询时间差不多？？
  2. 普通索引查询比主键查询还要快？？
image.png

        同样的MySQL，同样的配方，结果让人大跌眼镜！

为什么呢？

        经过一顿分析，并没有发现云rds与本机MySQL有什么区别。目前我正在寻找这个问题的答案，并且正在与阿里云官方积极沟通中，如果你知道其中原委，还请留言告知，不吝赐教！

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,294评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,493评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,790评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,595评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,718评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,906评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,053评论 3赞 410
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,797评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,250评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,388评论 4赞 332
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,018评论 3赞 316
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2赞 350