MySQL Index 联合索引探讨

联合索引也叫多列索引, 其常见的实现方式为连接索引(concatenated index), 它是通过将一列的值追加的一列后面形成的, 其连接的顺序由创建索引是指定, MySQL便是使用的这种方式. 另一种方式成为多维索引(multi-dimensional index), 这种方式比较复杂, 有兴趣的同学可自行搜索相关资料.

联合索引的创建

  1. 随表创建
CREATE TABLE `t_index_explain` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `a` varchar(20) DEFAULT NULL,
  `b` varchar(20) DEFAULT NULL,
  `c` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_a_b_c` (`a`,`b`,`c`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
  1. 单独创建
ALTER TABLE `t_index_explain` 
ADD INDEX `index_a_b_c`(`a`, `b`, `c`) USING BTREE;

如上两种方式, 都是创建了一个a, b, c 的联合索引, 其定义的顺序是abc,故在实际索引的中的每一个值为(a, b, c)这样一个连接组合形式, 甚至可以简单粗暴的理解为索引列的值就是a+b+c(以字符串的方式连接在一起). 如此就把多列索引变成了我们熟悉的单列索引. 其工作原理也是一致的.

用法与注意事项

联合索引遵循最左前缀原则, 原因是其索引值连接顺序为定义的从左至右连接, 因此如下SQL是可以使用index_a_b_c索引的:

SELECT * FROM t_index_explain WHERE a  = "1" and b = "1";

如下是该SQL的解释结果:


image.png

其中Extra 说明了我们确实使用了index, possible_keys说明了可能的index只有 index_a_b_c.

常见误区: 很多人认为, 所谓的最左前缀原则, 需要我们编写的SQL条件顺序与定义顺序一致, 其实不是的(查询优化器没那么傻), 如下佐证:

SELECT * FROM t_index_explain WHERE b = "2" and a  = "1";

把a, b 条件的顺序调换一下, 也会得到同样的解释结果. 其成立的条件应该是条件中是否包含index定义最左边的字段. 如下的sql与执行结果可证明这一点.

SELECT * FROM t_index_explain WHERE c = "2" and a  = "1";

image.png

不能使用索引的情况, 在本例中只要不包含a字段的查询, 都不能使用该联合索引(除非索引覆盖).

SELECT * FROM t_index_explain WHERE c = "2";
SELECT * FROM t_index_explain WHERE b = "2";
SELECT * FROM t_index_explain WHERE c = "2" and b = "1";

以上SQL解释执行结果:


image.png

其中Extra提示了Using Index但是possible_keys为NULL, key 中出现了我们创建的索引index_a_b_c, 其原因是发生了索引覆盖. 如果表中的字段/数据丰富一些, 多一些可以观察的不一样的执行结果, 有兴趣的同学可自证.

索引与排序

众所周知, 索引是有序的, 但是实际开发中索引字段, 与排序字段往往不是一个比如订单表中我们需要查询某个用户的数据, 但是按支付时间排序, SQL如下:

表:

CREATE TABLE `t_order`  (
  `id` bigint(0) NOT NULL AUTO_INCREMENT,
  `userid` bigint(0) NULL,
  `pay_time` datetime(0) NULL,
  PRIMARY KEY (`id`)
  KEY `index_userid` (`userid`) USING BETREE
);
select * from t_order where userid = 1 order by pay_time

如果创建的是userid的单列索引, 那么如上查询语句解释结果


image.png

可以看到Extra中出现了 Using filesort 表明该操作需要单独进行一次排序操作.

修改索引为联合索引:

ALTER TABLE `micro_stories`.`t_order` 
DROP INDEX `index_userid`,
ADD INDEX `index_userid_pay_time`(`userid`, `pay_time`) USING BTREE;
image.png

如上解释结果可以看出, 没有filesort了. 所以索引不只可以来做查询条件的, 也可以利用索引的有序性来做排序优化.

总结一下

  • 联合索引的每个索引值是以索引定义中字段的顺序, 连接在一起组成的, 其索引的基本结构仍然是B+树
  • 联合索引生效需要满足条件中存在索引定义最左边的字段(最左前缀原则)
  • 联合所以可用于辅助排序, 提升查询效率
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 196,165评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,503评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,295评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,589评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,439评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,342评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,749评论 3 387
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,397评论 0 255
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,700评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,740评论 2 313
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,523评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,364评论 3 314
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,755评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,024评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,297评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,721评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,918评论 2 336