姑苏薛衡芜做后端开发这些年，我接手过不少慢到让人抓手的查询。印象最深的一次，一张订单表不到三百万行，按用户ID查历史订单，接口响应时间稳定在2秒以上，DB监控里这条SQL天天霸榜。当时第一反应不是改SQL，而是先看了一眼执行计划：type=ALL，rows=290万，典型的全表扫描。解决办法就一行——建个普通二级索引，1.8秒直接降到30毫秒。就是那次之后我才意识到，创建索引这件事，看着简单，但很多人（包括当年的我）根本没有真正理解它背后的原理。这篇文章我想把MySQL创建索引这件事拆开聊透：底层为什么快，建索引前要想清楚什么，实际怎么建，哪些场景会失效，以及我在生产环境踩过的那些和索引相关的坑。
1. 索引的本质：一条慢SQL从2秒到30毫秒，B+树到底做了什么
1.1 没有索引时，MySQL是怎么找数据的
当你执行 SELECT * FROM orders WHERE user_id = 1024，InnoDB的处理路径是：从聚簇索引的第一个数据页开始，一页一页扫过去，把每一条记录取出来，判断 user_id 是否等于1024。这个过程叫全表扫描（type=ALL）。它最大的问题不在于读取的行数，而在于它不知道需要的数据在哪，所以只能老老实实把所有数据都读一遍。
三百万行的订单表，按每行平均200字节算，光数据就是600MB左右。就算数据在Buffer Pool里，也要消耗大量CPU逐行判断；如果数据大多在磁盘上，一次全表扫描就是几十万次随机读。机械硬盘每秒随机IOPS撑死两三百，算下来跑完几乎注定是秒级。这也是为什么explain里看到rows=290万时，基本可以直接判断这条SQL已经没有救的必要。
1.2 B+树：为磁盘IO而生的数据结构
索引能把这个过程从“扫描全部”变成“走树查找”，核心就是B+树。B+树和二叉树、红黑树最本质的区别是节点大小和磁盘页对齐：一个节点通常对应一个16KB的页，节点里能放几百个键值，所以树的层数非常矮。三层的B+树在InnoDB里就能撑起几千万行的数据，查找一条记录只需要几次磁盘IO左右。
InnoDB表本身就是一个按主键组织的B+树，也就是聚簇索引，叶子节点直接存完整的数据行。而你给 user_id 创建的普通索引是二级索引，它的叶子节点存的是主键值。查询流程是：先在 user_id 的二级索引树里找到匹配的叶子节点，拿到主键id，再回聚簇索引里取整行，这个过程叫回表。如果查询只要主键或索引字段，就能避免回表，这就是覆盖索引。理解了这三个概念，后面很多索引优化手段就顺理成章了。
1.3 索引的隐性成本：空间、写入、缓存
索引不是免费的。每次插入一行数据，除了写聚簇索引，还要往这张表上所有二级索引各插入一条；每次更新某个索引列，也需要同步修改对应的索引结构；删除更不用说。表上索引越多，写入路径越长，并发写入时锁竞争和页分裂的概率也越高。我见过有的团队给一张经常insert的表建了十几个索引，结果写入延迟从几毫秒飙到几十毫秒，最后不得不回头清理索引。
另外还有空间成本和内存成本。每个索引都是一棵B+树，数据量一大，每多一个索引就可能多出几百MB甚至几GB的磁盘占用。InnoDB的Buffer Pool是有限的，索引页越多，能缓存的数据页就越少。所以建索引前先想清楚：这条SQL是不是高频？是不是真的慢？这个列值的重复率是不是足够低？如果这三个问题没有想明白，建索引很可能是在给未来的自己埋雷。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手建索引前，先回答自己三个问题
2.1 到底给哪一列建索引？区分度先算清楚
建索引的第一原则是：要用在WHERE、JOIN ON、ORDER BY、GROUP BY这些高频过滤条件的列上。但并不是这些列都值得建。区分度是个关键指标，具体说就是这一列的取值种类数占行数的比例。一个性别列只有男/女/未知三个值，哪怕这张表有5000万行，它的区分度也只有极小，这种索引对查询的帮助几乎可以忽略，甚至可能因为回表次数太多比全表扫描还慢。
判断区分度可以直接执行：
sql复制SELECT COUNT(DISTINCT user_id) FROM orders;
SELECT COUNT(DISTINCT user_id) / COUNT(*) FROM orders;
通常我认为区分度达到0.1以上，也就是10%以上，才值得为单列建索引。如果是联合索引，原则是区分度高的列尽量放前面，同时要考虑实际查询条件的使用频率，不能只看区分度。比如 user_id 区分度很高，但业务里根本没有单独按它查的SQL，那把它放在联合索引第一位也没有意义。
2.2 单列索引够了吗？联合索引和覆盖索引怎么选
WHERE条件一般不会只有一个字段。比如查某个用户某个状态下的订单，单靠 user_id 索引可以把结果集缩小到几千条，再逐条过滤 status；但如果这条SQL是高频接口，最好直接建联合索引 (user_id, status)。联合索引的本质是先按第一个字段排，再按第二个字段排，所以它可以一次定位到所有匹配行，减少回表。
还有一点值得说：尽量让索引覆盖查询。比如你只需要查 user_id 和 status，联合索引叶子节点里已经有了这两个字段，查询直接就返回了，Extra显示 Using index，连回表都省了。但覆盖索引不是越宽越好，字段越多占空间越大。需要做的是拿高频SQL的SELECT字段和WHERE字段来综合设计，而不是机械地把所有查询列都塞进索引。
2.3 六种建索引语法，和不同存储引擎的差异
创建索引的入口其实有多个，但很多人只习惯用其中一两个。整理下来大致有这么多：
- 建表时在字段定义后直接写
KEY/INDEX； - 建表时在所有字段定义完后用
KEY/INDEX约束； - 建表时定义
PRIMARY KEY； - 已存在的表用
ALTER TABLE ADD INDEX； - 已存在的表用
CREATE INDEX； - 唯一索引用
CREATE UNIQUE INDEX或ALTER TABLE ADD UNIQUE。
这里要强调存储引擎的差异：InnoDB和MyISAM的普通索引底层都是B+树。MEMORY引擎支持HASH和BTREE索引，HASH索引适合等值查询，但不支持范围查询和排序。全文索引FULLTEXT在5.7之后InnoDB也支持了，专门处理 LIKE '%xxx%' 这种需求，普通BTREE索引对这种模糊查询无能为力。设计表结构的时候，想清楚引擎和索引类型的匹配很重要，否则索引可能建了也用不上。
3. 实操：从建表到线上加索引的完整命令
3.1 建表阶段把索引定义好
新表直接在建表语句里定义索引最省事。下面是一张常见用户表的DDL，我通常会按业务查询习惯把主索引和联合索引一起建好：
sql复制CREATE TABLE `user` (
`id` int NOT NULL AUTO_INCREMENT,
`user_name` varchar(64) NOT NULL,
`email` varchar(128) DEFAULT NULL,
`age` int DEFAULT NULL,
`city` varchar(64) DEFAULT NULL,
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_email` (`email`),
KEY `idx_user_name` (`user_name`),
KEY `idx_city_age` (`city`, `age`),
KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
需要注意，KEY 和 INDEX 在MySQL里是等价的，只是写法不同。PRIMARY KEY 是聚簇索引，一张InnoDB表只能有一个；UNIQUE KEY 除了索引还承担唯一约束，插入重复值会立刻报错。命名上我习惯用 idx_字段名 表示普通索引，用 uk_字段名 表示唯一索引，时间长了维护起来一目了然。
3.2 线上表加索引：ALTER TABLE / CREATE INDEX / 唯一索引
表已经上线后再加索引，最常见的是两种写法：
sql复制ALTER TABLE `user` ADD INDEX `idx_age` (`age`);
CREATE INDEX `idx_city` ON `user` (`city`);
两者效果完全一样，选择哪种纯粹看习惯。加唯一索引时我会加一层预防判断，比如先确认线上没有重复数据：
sql复制SELECT email, COUNT(*) FROM `user` GROUP BY email HAVING COUNT(*) > 1;
确认没有重复后再执行：
sql复制ALTER TABLE `user` ADD UNIQUE INDEX `uk_email` (`email`);
很多加唯一索引失败的生产事故，就是忽略了先查重复这一步。这步看起来多余，但线上数据经过多次迭代、手工修改，很可能已经存在不符合唯一约束的脏数据，直接建唯一索引会直接报错，甚至可能导致表被锁住。
3.3 查看索引、确认优化器真的用了它
索引建好后，用以下命令查看表上的索引信息：
sql复制SHOW INDEX FROM `user`;
返回的信息里有几个字段值得关注：Cardinality 表示这个索引的区分度估算值，数值越大说明索引质量越好；Seq_in_index 表示字段在联合索引中的位置；Sub_part 表示是否用了前缀索引。
执行计划才是判断优化器有没有用上索引的唯一标准：
sql复制EXPLAIN SELECT * FROM `user` WHERE city = '杭州' AND age > 18;
重点看 type、key 和 rows 三个列。key 是不是你刚才建的索引，rows 估算扫描行数有没有明显下降，type 是不是从 ALL 变成了 ref 或者 range。如果索引建了但执行计划没用，不用怀疑，去检查是不是命中了后文说的失效场景。
3.4 大表加索引的正确姿势：PT-OSC和gh-ost
这里必须要说一个生产环境的现实：几百万行甚至上千万行的表，直接执行 ALTER TABLE ADD INDEX，最坏情况下会长时间锁表，业务写入直接阻塞。MySQL 5.6之后支持 ALGORITHM=INPLACE，但具体也要看索引类型和表结构，而且仍可能占用大量IO，造成主从延迟。线上大表加索引，我建议用工具，而不是手写一条ALTER就去跑。
两个主流选择是Percona Toolkit的 pt-online-schema-change 和GitHub开源的 gh-ost。pt-osc的原理是先创建一张结构一致的空表，再把索引加上，然后通过触发器把原表的新增变更同步到新表，最后rename。gh-ost则更进一步，不依赖触发器，而是伪装成从库读取binlog来同步增量数据，对原库的压力更小。无论用哪个，都要在业务低峰期执行，准备好磁盘空间，并在执行前做好备份。这不是小题大做，我见过有人直接在千万级表上跑ALTER，结果主库锁了近十分钟，业务方差点当场报警。
4. 索引失效的七类典型场景与EXPLAIN排查法：建了索引不等于SQL能快
4.1 联合索引最左前缀：最常翻车的一类
联合索引 (user_id, status, create_time) 看起来很好，但如果你的查询条件是 WHERE status=1 AND create_time>某个时间，也就是跳过了第一列直接用第二列和第三列，那这个索引实际上是用不上的。B+树的联合索引排序规则是先按第一个字段排，再按第二个字段排，所以只有以第一个字段开始的查询才能走索引路径，这就是最左前缀原则。
更常见的情况是条件顺序不是索引定义的顺序，比如 WHERE status=1 AND user_id=1024，MySQL优化器通常会自动调整顺序，让它能命中索引；但如果你在条件里对 user_id 做了函数处理，比如 WHERE status=1 AND LEFT(user_id, 3)='102'，那优化器再聪明也没办法。判断一个联合索引到底用到了几个字段，可以通过explain里的 key_len 计算，后面小节会细说。
4.2 隐式类型转换和函数运算：让你的索引瞬间失效
这是我最常在新手代码里见到的问题。user_id 是varchar类型，业务代码里却传了一个数字进去，比如 WHERE user_id = 1024，MySQL会把索引列做隐式类型转换，等价于 CAST(user_id AS int)=1024，这样索引列一旦套上函数，优化器就只能放弃索引。
同样的问题还包括：对索引列做算术运算 WHERE age + 1 = 30；对索引列调用函数 WHERE DATE(create_time) = '2024-01-01'；以及 LIKE 条件用了前导通配符 WHERE user_name LIKE '%张%'。记住一个判断方法：如果WHERE条件里索引列本身参与了计算或函数，索引就会失效。正确的做法是让索引列保持裸状态，比如把 DATE(create_time)='2024-01-01' 改写成 create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'。
4.3 不等于、LIKE通配符、OR条件：优化器为什么放弃索引
有些人觉得索引建了就一定能用，实际上优化器有自己的成本评估。比如 WHERE age != 18，如果这一列90%的人都不是18，优化器算下来走全表扫描比走索引回表还便宜，它就会放弃索引。NOT IN 和 IS NOT NULL 在数据分布偏斜时也经常触发全表扫描。
OR条件是个独立的坑。SELECT * FROM user WHERE age > 18 OR status = 1，即使 age 和 status 分别都有索引，优化器可能还是要全表扫，因为它没有直接支持OR条件下同时使用两个索引的通用路径（8.0的Index Merge可以在部分场景下用，但有前提）。更好的办法是把OR改写为UNION ALL，让两个分支各自走索引，再合并结果。LIKE前导通配符会让B+树的无序前缀查找失效，因为索引树里 %张% 没有确定的起始位置，只能遍历叶子节点。
4.4 用EXPLAIN而不是猜：快速定位索引问题的完整链路
排查一条慢SQL有没有用好索引，我的固定套路是这样：先EXPLAIN看 type，type从优到劣依次是 const、eq_ref、ref、range、index、ALL。看到 const 说明是主键或唯一索引精确匹配，看到 ALL 基本就是全表扫描。
然后看 key_len，它可以算出联合索引实际用了几个字段。比如索引 (a,b)，a 是int占4字节，b 是varchar(64)且utf8mb4占最多260字节，如果 key_len 是4，说明只用了 a；如果 key_len 在264左右，说明 a 和 b 都用了。再看 Extra，出现 Using filesort 说明排序没走索引，出现 Using temporary 说明中间结果集用了临时表，这些都是在告诉你某个环节的索引设计有问题。最后把慢查询日志里的大SQL捞出来逐条过一遍，比凭感觉建索引高效得多。
5. 索引设计实战：一个订单系统的索引规划过程
5.1 先把业务查询模式列出来，再谈建索引
设计索引最忌讳拿到表就开始写字段。我的习惯是先把这张表在业务里的所有高频查询列出来，再为它们设计索引。以一张 order 表为例，核心字段有 order_no、user_id、shop_id、status、pay_time、amount。业务典型查询是：
- 按
order_no精确查订单，出现在交易回调里； - 按
user_id查用户全部订单，按状态和时间筛选； - 运营后台按
shop_id和时间段查订单列表； - 统计某个时间段内所有订单金额。
把这些查询模式写下来之后，索引规划就有了依据，而不是拍脑袋。如果业务里有 ORDER BY pay_time DESC 的分页需求，还得额外考虑排序方向的问题，这一点后面单独说。
5.2 联合索引设计、冗余索引清理
根据查询模式，可以做如下设计：order_no 业务唯一性很高，但它是业务编号而不是主键，所以加唯一索引 uk_order_no；user_id 维度最重查询，建联合索引 idx_user_status_time(user_id, status, pay_time)，这样 WHERE user_id=xxx AND status=1 ORDER BY pay_time 就能直接利用索引排序，避免filesort；shop_id 加联合索引 idx_shop_time(shop_id, pay_time)，配合后台时间段查询。
索引建多了以后，冗余是最容易被忽视的问题。联合索引 idx_user_status_time 的前缀 user_id 已经覆盖了单独 user_id 索引的查询能力，如果表上还有一个只有 user_id 的单列索引，那就是冗余，可以直接删掉。判断冗余的办法很简单：如果两个索引的前缀字段完全相同，且重复字段之外的后缀在另一个索引里也存在，低限制的那个就是冗余。
5.3 未使用索引的排查与统计
索引设计得再好，如果实际业务根本没按预期打过来，就是白耗空间。MySQL 5.7之后可以用 performance_schema 和 sys 库来查未使用的索引。最方便的命令：
sql复制SELECT * FROM sys.schema_unused_indexes;
它会列出自服务启动以来没有使用过的索引，跑一段时间之后拿这个结果去核对，删除那些确实是历史遗留的索引。不过要注意，这个查询对MySQL版本和 performance_schema 开关有依赖，生产环境先确认相关配置是开启的，否则查出来是空结果，排错容易走弯路。
5.4 一次线上索引变更：从发现问题到灰度上线的完整记录
曾经有一个订单查询接口，线上订单表约800万行，用户量增长之后按 shop_id 查业绩的报表接口越来越慢，从最初的300毫秒涨到5秒。我第一件事不是直接建索引，而是先打开慢查询日志，找出这条报表SQL，EXPLAIN确认它是全表扫描，唯一能救的字段组合是 shop_id + pay_time。然后我在测试环境复制了一份同量级数据，建上索引验证执行计划从 ALL 变成了 range，rows 从800万降到了6.4万。
上线时我选择用 pt-online-schema-change 在凌晨跑，参数是 --alter="ADD INDEX idx_shop_time(shop_id, pay_time)"，全程监控从库延迟，确认没有超过10秒，大约40分钟跑完。第二天再查同一条SQL，响应时间回到了300毫秒以内。整个过程最关键的不是那一条ALTER语句，而是之前的所有验证和选型，这些决定了线上变更是否安全。
6. 容易被忽略的索引细节：排序方向、前缀索引、唯一索引与字符集
6.1 索引列的排序方向：从ORDER BY说到降序索引
默认情况下，二级索引的每个字段都是升序排列，联合索引里第一个字段升序后，如果第二个字段也是升序，那 ORDER BY user_id ASC, pay_time ASC 就能直接走索引。但如果是 ORDER BY user_id ASC, pay_time DESC，MySQL 8.0之前的版本无法直接在同一个索引上反向扫描两个字段，只能用filesort。
MySQL 8.0引入了降序索引，定义索引时可以明确指定字段的排序方向：
sql复制ALTER TABLE `order` ADD INDEX idx_user_time(user_id ASC, pay_time DESC);
建索引前先想清楚业务排序需求，能省下不少filesort的代价。对于8.0以下的版本，如果排序方向不同，通常的做法是评估是否需要单独建一个索引，或者调整SQL写法，让排序方向和索引定义保持一致。
6.2 前缀索引：省空间但要看区分度
当索引列是超长字符串，比如URL、备注文本，完整字段建索引会占用非常大的空间，缓存命中率也会下降。这时可以用前缀索引，只索引列的前N个字符：
sql复制ALTER TABLE `user` ADD INDEX idx_email_prefix(email(10));
代价是前缀相同的不同行在索引里难以进一步区分，查询时可能会多回表判断几次。选择N的办法是观察区分度曲线：分别计算 COUNT(DISTINCT LEFT(email, 5))、COUNT(DISTINCT LEFT(email, 10))、COUNT(DISTINCT LEFT(email, 20))，在区分度与完整列接近的前提下取尽量小的N。这样做能明显缩减索引体积，尤其适合大字段的等值或前缀查询场景。
6.3 唯一索引和普通索引：别只看约束
唯一索引除了约束还有查询性能的差异。InnoDB里唯一索引在插入和更新时需要额外做一次唯一性检查，因此写入性能比普通索引要低一点；读取方面，由于唯一索引保证最多一行，优化器拿到目标后可以立刻停止，普通索引在二级索引里可能还要多走几步。对于业务上本来就不需要唯一约束、但查询又很高频的列，普通索引就够了，不要为了提高一点查询性能强行加唯一约束，结果反而拖慢写入和引发重复数据报错。
另外还有一个 change buffer 机制值得注意：普通二级索引的写操作可以缓冲，把多次随机写合并成顺序写；唯一索引因为有唯一性检查，不能走这个优化。对写入密集且二级索引较多的表，这个差距会被放大，可能在压测时才能明显感觉到。
6.4 字符集与排序规则：utf8mb4_general_ci和大小写问题
字符集和排序规则对索引的影响很多人会忽略。比如一张表的 user_name 列是 utf8mb4_general_ci，这个排序规则不区分大小写，那么 WHERE user_name='ZhangSan' 能查出来 zhangsan，但同时它在索引定位时也是按不区分大小写的规则去比较的，所以你建了唯一索引，可能 ZhangSan 和 zhangsan 会被认为重复。如果业务要求区分大小写，就得用 utf8mb4_bin 或 utf8mb4_0900_as_cs。
还有隐式字符集转换：两张表关联时，如果关联字段的字符集不同，MySQL会对其中一个做转换，索引列一旦套上转换函数，关联查询就走不上索引了。所以设计表结构时统一用utf8mb4，并保证关联字段的字符集和排序规则完全一致，能避免掉一大部分隐晦的性能问题。
6.5 存储过程、触发器里和索引相关的暗坑
存储过程和触发器本身不会让索引失效，但动态拼接的SQL容易把索引搞废。比如在存储过程里用 PREPARE 把变量直接拼进WHERE条件，如果变量是字符串且没有加引号，就会触发隐式类型转换，索引就没了。我见过一个定时任务的存储过程，占位符写错导致执行计划全表扫描，3分钟跑完变40分钟，排查了很久才发现是拼接SQL把日期类型转成了字符串。
触发器里也要格外小心：在对主表插入时，触发器内部的UPDATE如果更新的是带索引的列，并且频率很高，会放大索引维护的开销，还可能因为锁顺序不一致导致死锁。所以凡是涉及核心表的高频写入场景，触发器能不用就不用，索引的维护成本让数据库自己处理就够了。
最后分享一个我自己的习惯：每次要加一个新索引之前，我会先在测试环境做一次完整的EXPLAIN和真实数据量验证，再拿 sys.schema_unused_indexes 检查有没有可以顺带清理的冗余索引。索引不是越多越好，它本质上是拿空间和写入性能换查询性能，每一次创建都应该有明确的业务查询作为依据。