那是我第三次优化那张快 700 万行的订单表线上告警响得让人头皮发麻。某个常见的用户查询接口单次请求稳定在 2.5 秒左右而这个接口恰好又嵌在登录后的首页里某一拨推广活动直接把流量顶了起来数据库的 CPU 瞬间飙到 80%。当时第一反应是加机器、上缓存但冷静下来查了一遍慢查询日志发现罪魁祸首是一条很简单、甚至可以说相当常规的 SQLSELECT * FROM orders WHERE user_id 100234 AND status 1 ORDER BY created_at DESC LIMIT 20;就是一条用户订单列表查询字段都不复杂没有任何 JOIN、子查询。但它在全表扫描一查就是几秒。后来我在orders表上加了一个联合索引(user_id, status, created_at)那条 SQL 直接掉到 20 毫秒以内接口从“濒死状态”变成了“秒开”。整个过程没有换机器、没有改缓存策略、没有调数据库参数就只是加了几个索引。这件事让我彻底意识到一个事实很多人根本没把索引当回事直到慢查询打上门来才想起它。而索引就是给数据库装上的一套“导航仪”。没有它数据库就只能整表一个一个翻有了它数据查询直接走最快捷的路径。这篇文章我就拿这几年在项目里实际踩过、优化过的索引问题把 MySQL 索引从原理到实战完整拆一遍。不管你是刚入行的开发还是已经在生产环境里被慢查询折磨过的老手这篇文章应该都能给你一些实打实的参考。1. 先说清楚索引到底干了什么从一条 SQL 的“全表扫描”说起很多刚接触索引的同学对它的理解停留在“加了索引查询就变快了”这个层面。这当然没错但如果你真去调优慢查询会发现光知道“加索引”远远不够。你还得知道为什么加了索引就变快、快在哪里、以及什么时候它会失效。这些问题的底层都指向同一个东西索引的数据结构。1.1 数据的“住址”与目录页磁盘 IO 才是性能瓶颈要理解索引先理解 MySQL 的数据存储方式。表里的每一行数据物理上最终都存在磁盘上而 InnoDB 存储引擎操作数据的基本单位不是“一行”而是一个“页”默认 16KB。数据库每次读写数据至少要把一页磁盘数据加载到内存里再在内存里找你要的那一行。假设没有索引你想查某一行数据InnoDB 只能把整张表的所有数据页从头到尾扫一遍每一页都读进内存判断这一页里有没有你要的记录。这个动作就是“全表扫描” 磁盘顺序读一页 16KB可能只需要几毫秒但如果表里有 100 万行数据占了 60 万个数据页那全表扫描就是 60 万次磁盘读哪怕数据库做了预读优化这个量级的磁盘 IO 消耗也足以让一个简单查询慢到“无法忍受”。打个最直观的比方整张表就像一本完全没有目录的几百万页的大部头书籍。你想找一个特定的名词解释只能从第一页翻到最后一页运气不好翻到最后一页才找到。全表扫描就是这样代价随数据量线性增长。而索引本质上就是在书的最后面加了一个“拼音笔画目录页”。你查某个词之前先从目录页定位到它的页码再直接翻到那一页拿正文。1.2 B 树为什么 MySQL 选了它当导航仪既然要给数据加导航仪用什么数据结构来当“目录页”最合适答案是 B 树。MySQL InnoDB 引擎的索引几乎都是 B 树结构哈希索引是另一种后文会说。B 树这名字听起来学术你把它理解成“一棵倒挂的多层目录树”就好树的叶子节点存放真正指向数据行的索引键值和“数据地址”主键值树的非叶子节点只存放用于寻路的键值和指向下一层节点的指针同一层的节点通过链表串联起来从小到大有序排列。这个设计带来的实际收益是惊人的。因为非叶子节点只存索引键和指针一页 16KB 能容纳非常多的“目录项”。比如主键是 BIGINT8 字节加上一个 6 字节的行指针InnoDB 内部指针一页大概能存 16KB / 14字节 约 1170 个目录项。那么一棵三层高的 B 树能索引多少行数据算一下第一层 1 个根页能放约 1170 个指针第二层 1170 个页每个页又能放约 1170 个指针第三层叶子节点每个叶子页能放大约 16 行按每行 1KB 口径估算那 1170 × 1170 × 16大约能覆盖 2100 万行数据。也就是说在一张两三千万行的表里按主键查一条记录只需 3 次磁盘 IO读根页、读中间层页、读叶子页。对比全表扫描的几十万次 IO这差距就是“秒”和“毫秒”的区别。这个数据也解释了一个常见疑问“为什么不把整张表直接塞进内存”内存虽然快但容量有限、成本高数据库不可能靠纯内存扛所有场景。B 树的价值在于用极少的磁盘 IO解决了大规模数据的高效定位问题。注意以上计算基于“主键查询”的场景。二级索引非聚簇索引的叶子节点存储的是主键值所以通过二级索引查找数据需要先查索引树再拿主键回表查一次聚簇索引。这个“回表”动作后面会专门展开。1.3 聚簇索引与二级索引InnoDB 里的两套“导航系统”InnoDB 的索引结构并不是只有一种。按数据的组织方式它分成两大体系聚簇索引clustered index和二级索引secondary index。聚簇索引的特殊之处在于表的每一行数据本身就存储在聚簇索引的叶子节点上。InnoDB 默认通过主键构建这棵树。所以如果你建表时指定了主键主键就是聚簇索引如果你没指定主键InnoDB 会找一个非空的唯一索引当聚簇索引如果连唯一索引都没有InnoDB 会创建一个隐藏的row_id列作聚簇索引。这就解释了为什么我一直建议“每个表必须有主键”。没有主键聚簇索引是隐藏生成的你连按主键查询的机会都没有而且所有二级索引的回表目标都依赖这颗树有没有一个稳定的根。而二级索引解决的是“按其他列查询时怎么走捷径”的问题。比如CREATE INDEX idx_user_status ON orders(user_id, status);这就是一个典型的二级索引。它的叶子节点存储的是索引键值(user_id, status)以及对应行的主键 ID。查询user_id 100234 AND status 1时数据库先在索引树里快速找到符合条件的叶子节点拿到主键 ID再去聚簇索引里把完整的行数据“捞”出来。这个“拿主键再去聚簇索引查完整行”的过程就是回表。回表不是免费的。如果一条 SQL 命中的记录数很多每一条都要回表一次性能消耗同样很大。所以后来我优化那类“按索引过滤但又要查全字段”的查询时优先考虑用覆盖索引来干掉回表。这个细节在第四部分说。2. 索引不是银弹先选对类型不同索引的适用场景这是我在面试、带新人时最常遇到的一个认知断层很多开发知道“索引能加速”但不知道索引到底有哪些种类也不知道不同类型的索引适用什么场景。于是经常出现“索引建了一堆慢查询还是一堆”的情况。2.1 主键索引、唯一索引、普通索引它们到底差在哪按照索引的约束属性MySQL 里的索引大致分三类索引类型约束规则典型用途主键索引一个表只能有一个不允许 NULL唯一每行数据的唯一标识聚簇索引的构建基础唯一索引允许有多个值必须唯一可含 NULL业务上要求唯一但并非主键的字段如身份证号、订单号普通索引无唯一性约束可以有多个高频查询但取值可重复的字段如 user_id、status这里的核心区别不是“能不能加速”而是“约束规则不同”。唯一索引因为自带唯一性约束在 INSERT 和 UPDATE 时要做一次额外的唯一性检查比普通索引稍有写入开销。如果业务上完全不要求唯一别画蛇添足建唯一索引纯粹给自己增加无谓的锁检查。某次我在项目里见过一个很典型的滥用开发给一张订单表的order_status字段建了唯一索引。业务上这个字段只有 0、1、2 三个值且大量记录是相同状态。结果呢不仅索引完全发挥不了定位作用后面会说区分度问题写入时还白白增加唯一性检查成本。这种索引就是纯负资产。2.2 联合索引 vs 单列索引什么时候多列算“一个索引”如果你经常处理多条件筛选的查询比如WHERE user_id ? AND status ?你会发现单列索引在这个场景下有点“力不从心”。数据库一般只能选择其中一条索引来过滤另一列就得回表再筛。真正好用的方案是联合索引也就是把多个列合成一个 B 树索引。联合索引的 B 树结构有几个关键规则需要记住优先按第一列排序第一列相同的情况下按第二列排序以此类推查询必须从第一列开始命中才能用到这个索引这就是最左前缀原则联合索引也实现了对“排序”的加速因为索引本身是有序的。举个例子INDEX (user_id, status, created_at)这一个索引同时可以命中这些查询模式WHERE user_id ?WHERE user_id ? AND status ?WHERE user_id ? AND status ? ORDER BY created_at DESCWHERE user_id ? ORDER BY created_at DESC但如果你想WHERE status ?抱歉这个联合索引直接从第二列开始查是走不通的。因为 B 树的排序是先按 user_id 排的单独按 status 查等于在一本按“姓氏”排的通讯录里找所有“名字叫王”的人根本没有整理依据。这也是为什么很多索引优化文章会强调一句“把联合索引的列顺序按照‘等值条件优先、范围条件其次、排序字段最后’来排。”这句口诀在 90% 的场景下都很好用。2.3 全文索引与哈希索引别把万能钥匙塞进所有锁聊到索引类型还得提两个特殊角色全文索引和哈希索引。全文索引解决的是“模糊搜索”问题。普通的 B 树索引无法高效处理WHERE content LIKE %关键词%这种前缀带百分号的查询。全文索引通过分词和倒排表结构让这种“包含某词”的检索变快。但它的使用限制也很多只适用于 MyISAM 和 InnoDB分词规则受配置影响不适合做复杂的语义搜索。真要搜全文生产环境更成熟的选择还是专门搜索引擎MySQL 全文索引更适合轻量场景顶一顶。哈希索引在 InnoDB 中属于“自适应哈希索引”是数据库内部根据热点查询自动生成的优化结构开发人员一般无法手动指定MEMORY 引擎倒是可以手动建。它的特点是等值查询极快但不支持范围查询、排序。理解它的存在就行日常索引设计主要精力还是放在 B 树体系上。3. 一次事故复盘联合索引最左前缀是怎么“坑”人的光讲原理容易飘拿一个具体经历来讲最左前缀比背十遍规则都管用。先说我实际遇到过的一个线上问题。某业务系统的一张用户行为记录表有近 800 万行核心查询是SELECT * FROM user_actions WHERE action_type 3 AND user_id 10294 ORDER BY log_time DESC LIMIT 10;这张表原有的索引是(user_id, action_type)。按最左前缀原则action_type 3不能作为联合索引的第一列生效所以优化器在这条 SQL 里实际上只能用到user_id这一个等值条件。如果某个 user_id 的行为记录很多排序动作还得在临时文件里执行慢是必然的。那段时间这条查询平均耗时 800 多毫秒虽然不算“挂掉”但作为高频接口累计下来的压力不小。我们当时的调整方案是两步走新增一个联合索引(user_id, action_type, log_time)让等值过滤的两个条件都命中索引并且log_time利用索引天然有序的特性直接覆盖掉排序需求把SELECT *改成只查必要的业务字段进一步降低回表和传输开销。改完以后这条查询从 800 多毫秒降到 30 毫秒左右效果非常明显。这个案子里最关键的一步其实不是“加索引”本身而是理解最左前缀的时候不能“想当然”。(user_id, action_type)这个索引严格来说包含了两条可用的搜索路径user_id单独查或者user_id action_type一起查。而action_type单独作为起点是根本没法走这棵索引树的。你在看一段 EXPLAIN 结果时如果发现key字段虽然显示用到了某个索引但key_len明显偏短那就是典型的“只用到了联合索引里前面的若干列”。这时候不妨对照 SQL 条件确定是不是有列没被真正用上。3.1 联合索引的列顺序区分度大的放前面除了最左前缀之外设计联合索引列顺序还有一个关键指标区分度。区分度就是某个字段的值种类数占总行数的比例。比如一张表有 10000 行某个字段有 1000 个不同值区分度就是 10%。区分度越高过滤能力越强。在等值条件的场景下建议把区分度高的列放在联合索引的前面。举个例子INDEX(province, city, created_at)如果查询大多数时候带着 province 和 city而这两个字段的取值集合都不大省只有几十个市几百个这个索引过滤的效果就一般因为命中范围还是太大。反而是把created_at放前面对大跨度时间范围的查询更有区分度。但这里有一个取舍问题如果业务查询必须“先指定省份再查城市和时间”那么就算区分度不高也得把 province 放前面因为这是最左前缀的硬规则。规则优先于区分度区分度是在满足最左前缀前提下的调优策略。记住这个主次关系你就不会在列顺序上纠结太久。3.2 索引也能加速 ORDER BY 和 GROUP BY很多开发知道索引能加速 WHERE 过滤但忽略了索引对ORDER BY和GROUP BY同样有巨大帮助。原因还是 B 树叶子节点天然有序这一点。如果查询语句是SELECT user_id, COUNT(*) FROM orders WHERE created_at 2024-01-01 GROUP BY user_id ORDER BY user_id;若表上有(created_at, user_id)联合索引那么按 created_at 过滤后user_id 的值在索引扫描路径中也是按序分布的。数据库可以直接基于索引顺序做分组统计而不需要额外把数据抽取到临时表排序。这个能力在数据量大时能省下大把时间。但从实践角度看GROUP BY和ORDER BY的索引优化往往更容易被忽略因为日常在慢查询排查时大家的目光都集中在 WHERE 条件的过滤上。等你把 WHERE 条件都优化完了可以回头再看看这些“非过滤型”操作常常还有意外收获。4. 绕过回表的“覆盖索引”操作回表这个问题前面已经提过好几次。现在展开讲透它因为覆盖索引是日常优化中性价比最高的技巧之一。4.1 什么是回表它为什么会慢InnoDB 的聚簇索引和二级索引是两棵独立的树。二级索引叶子节点存的不是整行数据而是索引键值 主键 ID。所以当 SQL 查的字段超出了索引键范围数据库就必须用主键 ID 去聚簇索引里再查一次完整行。这个动作就像你先查目录知道页码再翻到正文那一页抄内容。回表本身是正常机制问题在于回表的次数。如果一条二级索引的等值查询命中了 1000 行就意味着要回表 1000 次。虽然 InnoDB 有各类优化但每一次回表都是额外的随机 IO成本不容小觑。4.2 覆盖索引让二级索引“自带”你需要的字段覆盖索引的本质是让查询的所有字段都包含在二级索引里这样数据库无需回表就能返回结果。比如你有一个索引(user_id, created_at)那么这条 SQLSELECT user_id, created_at FROM orders WHERE user_id 100234;在扫描索引树时就能直接拿到 user_id 和 created_at根本不需要回到聚簇索引取数据。这就是覆盖索引。实际优化中我经常把“SELECT *”改成“SELECT 需要的字段”然后结合查询模式来设计覆盖索引。因为“SELECT *”意味着所有列都必须回表才能拿到覆盖索引根本不可能发挥作用。4.3 覆盖索引的边界“SELECT *”永远做不了覆盖索引有一个很常见的念头“我能不能把(user_id, status, created_at)变成一个覆盖索引让所有订单查询都直接刺刀见红”理论上是可以做到但前提是这张表的字段非常少比如只有这些列。但真实的订单表动辄十几、二十几个字段不可能把全表字段都塞到二级索引里。索引列越多存储空间越大、写入维护成本越高、索引页能容纳的行数越少最终会拖垮整体性能。所以在实际项目中覆盖索引通常只用来覆盖“高频且字段少的查询”而不是试图覆盖所有查询。常见做法是把最常用到的组合(查询条件列, 排序列, 2~3个需要返回的列)做成一个联合索引让高频查询走覆盖路径。这样做的前提是你能对业务查询做“减法”改 SQL 只取必要字段。如果改动量大至少对压测里最热的几条 SQL 做覆盖优化收益已经相当显著。5. 学会用 EXPLAIN 给查询做“体检”优化的核心能力不是背规则而是会看懂数据库是怎么执行一条 SQL 的。MySQL 里最实用的工具就是EXPLAIN。它不会真正执行你的查询而是通过优化器模拟输出这条 SQL 的执行计划。看懂了执行计划就能判断索引到底有没有用上、用得好不好。5.1 关键字段逐个拆解一个典型的EXPLAIN输出长这样虚构示例EXPLAIN SELECT * FROM orders WHERE user_id 100234 AND status 1 ORDER BY created_at DESC LIMIT 20;输出大概有这些关键列字段含义实际参考标准type访问类型从好到差system const eq_ref ref range index ALLkey最终选用的索引如果为 NULL基本可以确认没有走索引key_len索引中使用到的字节长度联合索引中能用多少列看这个值是否“够长”rows优化器预估需要扫描的行数越小越好量级越大说明过滤性越差Extra额外信息出现 file sort / Using temporary 通常意味着排序或分组没走好索引在真实优化中我关注最多的是type和Extratype如果显示ALL基本可以断定这条 SQL 在“全表扫描”。值const和ref是相对健康的状态Extra如果出现Using filesort代表ORDER BY没有用上索引数据库要把结果集抽出来额外排序。请记住在数据量大时文件排序就是性能杀手。5.2 从 EXPLAIN 结果反推索引设计给你一个我在项目里的实战套路。某条 SQL 的 EXPLAIN 结果type: ref key: idx_user_id key_len: 8 rows: 13500 Extra: Using where; Using filesort这个结果里有三个信号走到了索引idx_user_id但 key_len 只有 8说明只用了user_id这个等值列rows 有 1.3 万行说明某个用户的数据量大过滤不够彻底Using filesort说明排序字段没有进到索引里。针对这三件事我们重设计了索引ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, created_at);再跑一次 EXPLAIN结果就会变成type: ref key: idx_user_status_time key_len: 13 rows: 120 Extra: NULLrows 从一万多降到一百多filesort 消失整体延迟自然也就打下来了。有些读者会问直接改 SQL 不也能优化吗比如强制加一些条件。但实际上业务 SQL 往往不能轻易改逻辑最稳妥的优化就是“在不改变业务语义的前提下通过调整索引让执行计划更优”。EXPLAIN 就是验证这个“更优”的唯一标尺。6. 索引失效的 N 个常见姿势网上学不到的“踩坑实录”可能有人会有这种经历“索引建了EXPLAIN 看也是走了索引但就是慢。”或者在更常见的情况“明明这条 SQL 很标准索引却死活没生效。”这些问题的根源通常是索引失效。下面列几个我在实际项目中反复遇到的高频场景。6.1 隐式类型转换让索引“裸奔”MySQL 里隐式类型转换是索引失效的重灾区。最经典的案例某张表的order_no列类型是 VARCHAR但 SQL 查询时传了数字SELECT * FROM orders WHERE order_no 20240001;MySQL 会把字符串列和数字比较时进行类型转换等于在索引列上套了一层“函数”。一旦索引列被函数包裹B 树的有序性就失去了直接比对的价值优化器只能放弃索引。如果你 EXPLAIN 这条 SQL大概率看到type: ALL。解法很直接传参保持和列类型一致或者把列类型改成与业务形态匹配的类型。比如订单号如果是数字字符串尽可能统一用字符串类型定义不要为了省存储空间改成 BIGINT。6.2 函数包裹、模糊前缀、OR 连接三个高频杀器在索引列上使用函数WHERE DATE(created_at) 2025-04-18会让索引失效。正确做法是WHERE created_at 2025-04-18 AND created_at 2025-04-19让列保持原值不被包裹。前导模糊查询WHERE user_name LIKE %clown%这个查询方式因为字符串匹配不知道前缀索引树的有序性无法利用。但WHERE user_name LIKE clown%就可以正确走索引。OR 连接条件中有一个非索引列WHERE user_id 100234 OR status 5这种写法MySQL 要处理“或者”的两个分支如果没有对status单独建索引整体扫描基本得退化为全表。解法是把 OR 拆成两条 SQL 然后用UNION合并或者把status也放进联合索引的第一列。注意OR 连接即便两个列都建了索引优化器也不一定都能正确合并使用。两列都在索引且数据分布均匀时要看优化器心情。最稳妥的方案是改造成 UNION。6.3 范围查询对索引后续列的“阻断”这是一个很多人没意识到的小坑联合索引中如果某一个列用了范围查询大于、小于、BETWEEN 等它后面的列将无法用于索引过滤。举例说明INDEX(a, b, c) SELECT * FROM t WHERE a 1 AND b 10 AND c 2;在这个查询里a 1走索引定位b 10也能使用索引范围扫描但c 2无法再借助索引了因为 b 的范围查询产生的区间内c 并不是有序状态优化器只能在这个区间里逐行过滤。这个限制不是 MySQL 的缺陷而是 B 树排序结构决定的。设计联合索引时要把范围查询列尽量放到后面把等值条件列放到前面以减少范围对后续列的影响。这一点和 3.2 节说的“范围条件靠后”的部署原则是一脉相承的。7. 索引设计的长期主义如何给索引做“瘦身”和“增补”索引不是建一次就完事。生产环境里的索引设计更像是对表结构持续“动手术”的过程。随着业务变化、数据量增大旧索引会逐渐不合身。这个部分聊聊我在项目中如何体系化地管理索引。7.1 建索引前先想清楚这几个问题每次收到需求或者排查慢查询我会先自查一遍这几个问题业务是否足够高频如果一个字段根本不在 WHERE、JOIN、ORDER BY、GROUP BY 里出现建索引就没意义。字段区分度是否够高如果一个字段只有 0、1、2 三个值区分度低到离谱索引过滤能力极差还占空间。这种字段适合做成位图统计或在业务层做汇总表而不是建立普通 B 树索引。联合索引是否冗余一个(a, b, c)联合索引等价于同时拥有(a)、(a,b)、(a,b,c)三个索引的能力。如果你已经建了(a, b, c)再单独建一个(a)就是完全冗余的。优化索引时最常见的负资产就是冗余单列索引。比如一张表已经有INDEX idx_user_status_time (user_id, status, created_at)后来有人又建了INDEX idx_user (user_id)那么这个idx_user就是多余索引。它不仅让 INSERT、UPDATE 的写放大加倍还占用额外磁盘空间。7.2 定期用一条 SQL 找出冗余索引MySQL 的 schema 表里隐藏着所有索引信息。有一个实用的自查 SQL可以查出不同索引之间是否存在“重复前缀”SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, COLUMN_NAME, SEQ_IN_INDEX FROM information_schema.STATISTICS WHERE TABLE_SCHEMA 你的库名 ORDER BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX;拿到结果后你就能对比哪些索引的列组合完全一样、或者前者是后者的前缀。这些冗余索引可以安全地 DROP前提是确认没有其他 SQL 单独用前缀列查询。“安全地”三个字是关键别指望一个 SQL 全自动清你最少要把每个删除索引可能影响的查询确认一遍。7.3 索引维护别忽略碎片与统计信息在实际项目里索引还有一个容易忽略的维护点碎片与统计信息陈旧。InnoDB 的表和索引在随机删除、更新后页结构会产生碎片导致磁盘读取的“实际跨度”变大。即使仍然走索引整体 IO 成本也会上升。常规做法是定期执行表优化如ALTER TABLE table_name ENGINEInnoDB或OPTIMIZE TABLE但要注意这类操作会锁表不要在业务高峰执行。另外MySQL 优化器依赖统计信息判断走哪个索引。如果统计信息过期它可能选错索引。尤其是频繁更新的表建议在业务低峰期执行ANALYZE TABLE让统计信息保持相对新鲜。8. 索引选择和 SQL 改写一次完整的调优流程记录有的读者可能会问前面讲了这么多能不能给一个“遇到慢查询到底怎么一步步做”的完整流程下面用我几个月前处理过的另一个真实案例串一遍。8.1 问题背景某后台管理系统的权限节点表有约 300 万行查询模式非常集中SELECT role_id, node_code, node_name FROM user_roles WHERE role_id 1245 AND node_status 1 ORDER BY node_code;这个查询在高峰期经常要 200 多毫秒虽然不算慢到不可接受但后台管理页面有大量分批请求聚合起来对数据库压力不小。8.2 EXPLAIN 诊断第一轮先跑 EXPLAINtype: ref key: idx_role_id key_len: 8 rows: 14500 Extra: Using where; Using filesort结论明确role_id用上了索引但node_status和order by node_code都落在索引覆盖范围之外。每个角色 1.4 万行这个基数太大了。8.3 索引重构根据查询条件等值 role_id、等值 node_status、排序 node_code把索引调整为ALTER TABLE user_roles ADD INDEX idx_role_status_code (role_id, node_status, node_code);同时检查业务里是否还有其他 SQL 只用了role_id。确认没有后DROP 了旧的idx_role_id避免冗余。8.4 效果验证修改后再次执行 EXPLAINtype: ref key: idx_role_status_code key_len: 12 rows: 16 Extra: NULLrows 从 14500 降到 16filesort 已经不存在。实际压测中这条查询的 99 分位延迟从 240 毫秒降到 18 毫秒数据库整体 CPU 负载也明显下降。这个案例的意义在于它展示了“诊断 → 设计 → 验证 → 维护”的完整链路。优化不是玄学不是“多加几个索引”碰运气而是基于执行计划的一次次精确调整。9. 索引之外那些让你“白忙一场”的隐形因素把索引设计得很完美了有时慢查询依然存在。我遇到过几次类似情况排查到最后发现“罪魁祸首”并不在索引本身。如果你想做真正的查询性能调优这几个坑绕不开。9.1 表数据量大得已经超出“索引红利”索引本质上是用树形结构换取“更少的磁盘 IO”。但如果表数据量已经超过内存缓冲池的容量且业务查询又是大范围的扫描型请求那么即便走了索引页面仍然可能反复从磁盘换入换出性能一样上不去。对这种场景单纯的索引优化已经到天花板了。你需要考虑的是数据归档、分区表或用专门的分析型数据库把“热数据”和“冷数据”分开。索引只是导航仪但一条高速公路如果满是大货车再好的导航也快不了。9.2 小表别硬建索引这是一个反直觉的结论过小的表索引可能无法帮你提速反而拖慢写入。假设一张配置表只有 200 行全表扫描只需要读一小块数据建立索引后的额外树查找未必比扫描更快且每次写入都要维护索引结构。从我个人习惯来看千行以下的字典表、配置表基本不需要索引。真正需要索引的是那些行数达到一定规模、且查询模式固定的业务大表。9.3 缓存与连接池索引之前先看系统设计很多慢查询发生在“热点数据被大量重复查询”的场景。比如某个商品详情页每天被请求上万次每次都打数据库。你花半天时间优化索引发现 RT 从 100 毫秒降到 50 毫秒但加一层 Redis 缓存之后RT 直接变成 5 毫秒。这两者不是互斥关系但顺序很重要。遇到性能瓶颈先想想这个查询真的必须每次都打到数据库吗如果能用缓存扛住 90% 的重复流量数据库的压力会大幅下降索引优化的压力也小得多。10. 写在你动手建索引之前我的个人心得这篇文章到这儿核心内容其实已经讲透了。最后分享几点我在实际项目中总结出来的“心法”它们不像前面那些参数和原理那么硬核但对长期维护一个健康数据库很有帮助。第一索引是“设计”出来的不是“补救”出来的。新表上线前我把业务高频 SQL 整理出来对着 SQL 设计索引远比上线后遇到慢查询再补救要省力得多。建表的 DDL 里就携带索引设计远比后期ALTER TABLE修改要优雅。第二索引越多写放大越严重。每次 INSERT、UPDATE、DELETE 都要维护索引树。一张表建了 10 个索引写入耗时就是 10 倍级别的放大。宁缺毋滥是索引设计的守则。第三监控慢查询日志是最高优先级。没有数据就没有优化方向。同时观察sys.schema_unused_indexes视图找出那些建了却从来没被用过的“僵尸索引”果断删掉。它们除了占存储、拖写入毫无贡献。第四一个优秀的 DBA 或后端不应该只会加索引还得会“减索引”。每次上线变更时顺手检查一下有没有冗余索引可以删。让表结构保持干净比今天加一个明天加一个更重要。如果这篇文章对你有用建议你现在就打开你负责项目的数据库跑一遍SHOW INDEX FROM 你的核心表再拉一份慢查询日志对照着看看有没有能立刻优化的点。很多性能问题在你真正动手去看它的那一刻就已经解决了一半。