【实测版】联合索引,最左匹配原则,走?不走?

本文基本基于Explain做分析,如果不太了解可以先移步下文(。・ω・。)ノ

了解MySQL的Explain,读这一篇够了( ̄∇ ̄)/

开始✊✊✊

建表

我们先创建一个表

less 复制代码
CREATE TABLE `aqin_index` (
    `id` BIGINT(20) UnSIGNED NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL,
    `card_no` VARCHAR(50) NOT NULL,
    `time_created` DATETIME DEFAULT CURRENT_TIMESTAMP,
    `note` VARCHAR(100) NOT NULL,
    PRIMARY KEY (`id`),
    INDEX `index_unit` (`name`,`time_created`,`card_no`) USING BTREE) 
    ENGINE=InnoDB DEFAULT CHARSET=utf8;

Message字段显示OK则表示创建成功

这里创建的时候直接添加了一个联合索引

scss 复制代码
INDEX 索引名称 (字段1,字段2,字段3) USING 索引方法
  • 索引名称:自己起个就成
  • 字段1,字段2,字段3:想要添加的联合索引的所有字段(需要注意顺序)
  • 索引方法:一般选择BTREE(BTREE/HASH)

也可以在现有的表中添加

go 复制代码
ALTER TABLE `aqinindex`  ADD INDEX `index_unit` (`name`,`time_created`,`card_no`)

插入数据

创建函数

sql 复制代码
-- 插入百万数据
DELIMITER $$
CREATE FUNCTION mock_data_4_aqin_index()
RETURNS INT

BEGIN
        DECLARE num INT DEFAULT 1000000;
  DECLARE i INT DEFAULT 0;
        
  WHILE i < num DO
  -- 插入语句
  INSERT INTO `aqin_index`(`name`,`card_no`,`note`)VALUES
  (CONCAT('name-',i), CONCAT('18', FLOOR(RAND()*((999999999-100000000)+100000000))),
  CONCAT('note-',FLOOR(RAND()*2), UUID(), FLOOR(RAND()*100)));
     SET i = i+1;
   END WHILE;
   RETURN i;
        
END;

Message字段显示如上图即为执行成功

调用函数

scss 复制代码
SELECT mock_data_4_aqin_index()

Message字段显示如上图即为执行成功,瞅一眼咱们生成的数据

删除函数

sql 复制代码
DROP FUNCTION 函数名
  • 注意⚠️此处的函数名是不加括号的

我们浅浅的测试下

执行测试语句

csharp 复制代码
EXPLAIN select  * from aqin_index where name = 'name-9999' and time_created="2023-01-09 16:37:56" and `card_no` = '18432153441'

可以看出type类型是ref,key_len值为310(三个字段长度和),走了联合索引并且3个字段都用上了

计算方式可以参考了解MySQL的Explain,读这一篇够了( ̄∇ ̄)/

  1. 替换三个字段的顺序

各个参数无变化

结论:字段都有,换顺序对结果无影响

  1. 删除第一个字段

type类型是ALL,即走了全表查询

结论:第一个字段缺失则不走索引

  1. 删除其他字段

type类型是ref,key_len值为158,用到了联合索引,但是只用了两个字段(name和time_created)

结论:第一个字段存在,就会使用联合索引,其他字段缺少只会影响用到索引的字段数

特殊情况

分析下上面两张图,他们的type类型是index,使用了全索引扫描,相比较ref挺慢的其实

分析下上面两张图,他们的区别在于查询的字段是否被联合索引覆盖,card_no在联合索引中,type类型是index,note不在type类型是ALL,index的性能虽然不如ref但优于全表扫描ALL

总结

联合索引的各个字段可以不按顺序出现(原因是WHERE后面字段的顺序会被优化器优化为符合最左前缀的顺序),但是第一个字段必须出现,否则不走索引(最左前缀匹配,即WHERE条件必须有联合索引的第一个字段,以最左边的为起点任何连续的索引都能匹配上),当SELECT后需要查询的字段被联合索引覆盖,也会走索引,但方式是进行全索引扫描,效率并不高。

相关推荐
Lyyaoo.18 小时前
Redis基础
数据库·redis·缓存
杨云龙UP19 小时前
ODA登录ODA Web管理界面时提示Password Expired的处理方法_20260423
linux·运维·服务器·数据库·oracle
解救女汉子19 小时前
SQL触发器如何获取触发源应用名_利用APP_NAME函数追踪
jvm·数据库·python
weixin_5206498721 小时前
数据库函数
数据库
Bert.Cai21 小时前
MySQL LPAD()函数详解
数据库·mysql
OnlyEasyCode1 天前
Navicat 任务自动备份指定数据库
数据库
if else1 天前
Redis 哨兵集群部署方案
数据库·redis
yejqvow121 天前
Pandas 高效实现组内跨行时间戳匹配与布尔标记
jvm·数据库·python
了不起的云计算V1 天前
从DeepSeek V4适配看国产算力的三个拐点
数据库·人工智能
qq_189807031 天前
html标签如何提升可访问性_aria-label与title区别【指南】
jvm·数据库·python