MySQL优化实战：从B+树索引到SQL改写与分库分表

1. 为什么你的MySQL越来越慢：先搞清楚瓶颈再动手

先讲一个我经历过的真实场景。某个线上核心接口平时稳定在 30ms 上下，某天突然飙到 800ms，数据库 CPU 直接 90% 以上。同事第一反应是“赶紧加 Redis 缓存”“不行就分库分表”，我拉了一下慢查询日志，发现问题只是一张订单表上新加的索引没走对，一条 SQL 扫了 500 万行。把索引修正之后，接口恢复到 25ms，全程没动一行缓存代码。MySQL 优化这件事，绝大多数瓶颈其实就集中在索引设计、SQL 写法、数据架构三个层面，而且 90% 的问题靠索引和 SQL 就能解决，根本走不到分库分表那一步。

这篇博文想把我这些年做 MySQL 优化的完整思路梳理出来，内容包括索引从原理到实战的细节、慢 SQL 怎么定位和改写、什么时候才真正需要分库分表，以及整个优化流程应该怎么排序。适合刚接触数据库优化、对 Explain 还不太熟的后端开发，也适合已经扛过几次线上告警、想把自己的排查方法体系化的同学。不管你是 MySQL 5.7 还是 8.0，大部分内容都通用，只要跟着思路走一遍，至少能解决掉线上 80% 的“数据库变慢”问题。

1.1 慢不是玄学，先建立你自己的优化决策树

很多同学遇到数据库慢，第一反应是“服务器不行”或者“MySQL 配置不对”，然后一顿调 buffer pool、改刷盘策略，结果该慢还是慢。我建议你任何时候都按这个顺序排查：先看是不是 SQL 本身有问题，再看是不是索引缺失或失效，然后是数据量是否大到索引都扛不住了，最后才轮到配置和架构调整。这个顺序非常重要，因为 SQL 和索引层面的一行改动，往往比调十个配置参数效果都好。

我自己的习惯是遇到慢查询先问四个问题：这条 SQL 是全表扫描还是走索引？扫描了多少行？回表了多少次？排序或临时表有没有落地磁盘？前三个问题通过 Explain 就能回答，第四个问题看 Extra 字段里的 Using temporary 和 Using filesort。如果这四个问题都确认过了还慢，再去分析是不是锁竞争、IO 瓶颈或者主从延迟，方向对了，优化才有效率。

1.2 不同数据量级，优化手段完全不同

MySQL 的性能优化没有银弹，数据量不同，解决方案天差地别。百万级以内，做好索引基本就能保证查询毫秒级返回；千万级，需要认真设计索引、改写 SQL，避免深翻页；到了亿级，单纯的索引优化可能就不够用了，读写分离、分库分表、归档冷数据才会真正提上日程。

这里有个很关键的认识：千万别在数据量还小的时候就把分库分表上了。分库分表带来的复杂度是明显的，跨库查询、分布式事务、全局唯一 ID、数据迁移这些都得处理，而大多数业务在单表单行不超过 2000 万、单表存储不超过 20GB 的情况下，只要查询模式设计合理，MySQL 完全撑得住。先把索引和 SQL 做扎实，分库分表应该是最后一道防线，而不是第一件武器。

2. 索引优化实战：从B+树到索引下推，一次讲透

2.1 B+树到底快在哪：为什么索引能大幅减少磁盘IO

索引能加速查询，本质上是因为它把“随机扫描”变成了“有序查找”。MySQL 的 InnoDB 引擎用的是 B+ 树，你可以把它理解成一个多层级、有序、适合磁盘存储的目录树。为什么不用二叉搜索树？因为二叉树深度太深——2000 万条数据，二叉树需要二十多层，每层一次磁盘 IO，查询就要二十多次 IO，而 B+ 树每个节点能存很多键值，2000 万数据三层到四层就能覆盖完，查询只需要三四次 IO，差距是数量级的。

B+ 树的另一个特性是只有叶子节点存数据，非叶子节点只存索引键，这使得非叶子节点能容纳更多键，树更矮。而且叶子节点之间用链表串联，范围查询时，找到起点后顺着链表往后扫就行，不需要反复从根节点重新查找。像 where create_time >= '2024-01-01' and create_time < '2024-02-01' 这种 SQL，B+ 树天然就擅长。这也是为什么 MySQL 的索引最终选择了 B+ 树，而不是跳表或者哈希索引——哈希索引做等值查询很快，但一遇到范围查询就无能为力了。

2.2 聚簇索引与普通索引：搞清楚回表才能理解“覆盖索引”

InnoDB 的表默认会根据主键建一个聚簇索引，聚簇索引的叶子节点直接存整行数据。也就是说，按照主键查数据，一次索引查询就能拿到全部字段，性能是最优的。其他普通索引，叶子节点存的是主键值，而不是数据行本身。当你用普通索引查询时，会先通过普通索引找到主键值，再拿着主键值去聚簇索引里找完整行数据，这个过程就叫“回表”。

回表次数多了性能就要打折扣。一次查询如果通过普通索引命中了 1000 行，就要回表 1000 次，每次都是一次随机 IO。解决回表问题最直接的方式就是覆盖索引：让查询要的所有字段都包含在同一个索引里，这样查询走普通索引时，直接能从索引里取到全部数据，就不需要回表了。比如你经常执行 select name from user where age = 20，那就建一个 (age, name) 联合索引，查询走索引就能直接返回 name，完全避免回表。

从实际优化经验来看，覆盖索引是成本最低的优化手段之一。不需要改任何 SQL，只要调整索引结构，性能就能成倍提升。但也要注意，不要为了让所有查询都“覆盖”而把几十个字段都塞进索引，索引字段多了，维护成本会急剧上升，写入变慢，索引体积变大，缓存命中率反而下降。

2.3 联合索引设计：最左前缀原则和字段顺序的讲究

联合索引是 MySQL 优化里最容易踩坑的地方。核心规则是最左前缀原则：一个联合索引 (a, b, c)，可以被 where a = ?、where a = ? and b = ? 这样的查询使用，但 where b = ?、where c = ? 这种跳过第一列的查询，走不了这个索引。本质上，联合索引先把 a 排序，a 相同时再按 b 排，再按 c 排，它是一棵组合排序的树，跳过最左列就失去了有序性。

我给业务设计联合索引时，有两条核心经验。第一，把区分度高的字段放前面。比如城市字段可能只有几十个不同值，而用户 ID 可能有上百万个，把用户 ID 放在最左边，查询时能快速缩小范围。第二，尽量让索引能覆盖查询中最常用的等值条件和排序字段。比如订单表经常按 merchant_id + status + create_time 查询，那就建一个 (merchant_id, status, create_time) 联合索引，这样既能等值过滤，又能让 order by create_time 直接走索引有序性，不需要额外的文件排序。

还有一个我常跟团队强调的点：冗余索引问题。已有一个 (a, b) 索引，又单独建一个 a 索引，后者就是冗余的，因为它完全能被前者覆盖。每多一个索引，Insert、Update、Delete 时都要额外维护一棵 B+ 树，写入性能必然下降。所以定期检查 sys.schema_unused_indexes，把那些建了但从来没走过的索引清掉，是很值得做的日常维护工作。

2.4 索引失效清单：这些写法会让索引白建

索引设计得再好，SQL 写法不对，优化器也走不上索引。我在代码评审里最常见的几类问题如下：

• 对索引列使用函数或运算。比如 where DATE(create_time) = '2024-01-01'，这种写法让索引列参与函数计算，B+ 树的有序性被破坏，优化器只能放弃索引。改成范围条件 create_time >= '2024-01-01' and create_time < '2024-01-02' 就能走索引。
• 隐式类型转换。表里 phone 字段是 varchar 类型，查询写 where phone = 13800138000，MySQL 会把字符串转成数字比较，结果索引失效。解决办法就是确保字段类型和参数类型一致，这也是为什么我建议应用层传参时保持类型清晰。
• 联合索引不满足最左前缀。前面已经说过，跳过索引最左列执行查询，索引直接失效。
• like 前缀模糊。where name like '%张三%' 这种搜索，因为通配符在开头，无法利用 B+ 树的有序性，索引失效。数据量小可以接受全表扫，数据量大的话就得考虑用全文索引或者外部搜索引擎。
• 用 or 连接条件。where age = 20 or name = '张三'，如果 age 有索引但 name 没有，优化器可能选择全表扫。改写思路是拆成两个查询 union all，或者给两边都建立索引。
• 对索引列做判断 is not null。MySQL 对 IS NULL 有时能走索引，但 IS NOT NULL 大多时候会走全表扫描，因为优化器认为“不等于空”的范围太大，不如全扫。

还有一个很容易被忽略的点：索引下推（Index Condition Pushdown）。MySQL 5.6 之后引入 ICP，可以在索引遍历过程中，直接对索引包含的字段做过滤，减少回表次数。比如联合索引 (age, city)，查询 where age = 20 and city = '北京'，如果没有 ICP，MySQL 先通过 age 找到主键，再回表看 city；有了 ICP，在索引内部就把 city 判断掉了，只有满足条件的行才回表。这一特性对 like '张%' and age = 20 这种场景特别有效。

2.5 索引维护细节：区分度、统计信息和碎片问题

索引不是建完就一劳永逸。如果表长期高频写入，索引的统计信息可能过期，优化器对“走索引还是全表扫”的判断就会失真。我一般会在业务低峰期跑一下 ANALYZE TABLE 表名 更新统计信息，有时候一个 ANALYZE 就能让原本走偏的执行计划恢复正常。

关于索引字段的选择，我建议建索引前先算一下区分度，用 SELECT COUNT(DISTINCT 字段) / COUNT(*) FROM 表名 看看比例。区分度太低，比如性别字段只有“男/女”，走索引扫出来的行数太多，回到聚簇索引的成本比全表扫描还高，优化器自然不会选它。一般字段区分度要超过 20% 才考虑单列索引，联合索引则看整体前缀区分度。

碎片问题也很常见。频繁的删除和更新会让 B+ 树叶子节点产生逻辑碎片，表物理文件比实际数据大，扫描起来更慢。我一般用 ALTER TABLE 表名 ENGINE = InnoDB 在低峰期重建表清理碎片，或者用 pt-online-schema-change 这类工具做在线操作，注意 5.7 和 8.0 的在线 DDL 支持度有所不同，尽量别在业务高峰期直接跑大表 ALTER。

3. SQL优化：高频慢SQL的定位思路与改写方案

3.1 先从 Explain 入手：Type、Key、Rows、Extra 怎么看

优化 SQL 之前，一定要学会读执行计划。EXPLAIN SELECT ... 输出里的几个核心字段，基本决定了一条 SQL 的性能走向：type 从好到差依次是 system、const、eq_ref、ref、range、index、ALL，看到 index 和 ALL 就要警惕；key 是实际用到的索引；rows 是优化器估算扫描的行数，越小越好；Extra 里的 Using filesort、Using temporary 都是明显的性能预警。

举个例子，我建一张订单表做演示：

sql复制CREATE TABLE `order_info` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL,
  `user_id` bigint NOT NULL,
  `status` tinyint NOT NULL DEFAULT '0',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_status` (`user_id`, `status`)
) ENGINE=InnoDB;

如果我执行 SELECT * FROM order_info WHERE status = 1，Explain 大概率会显示 type 为 ALL、rows 接近全表行数，因为 status 不在任何索引的最左列。如果改成 WHERE user_id = 100 AND status = 1，就走上了 idx_user_status 这个联合索引，type 为 ref，rows 从百万级降到个位数。所以拿到一条慢 SQL，第一件事不是猜，而是先跑一次 Explain，看它到底扫了多少行、走了哪个索引。

3.2 深翻页优化：Limit 深翻页为什么越查越慢

分页接口是最容易被忽视的性能陷阱。LIMIT 1000000, 20 看着只取 20 条，但 MySQL 必须先把前 100 万条全部扫出来，再丢弃前面 100 万条，最后返回 20 条。前面的 offset 越大，查询越慢，这就是深翻页问题。

我常用的优化方案有三种。第一种是延迟关联：先通过子查询或内连接查出来一页的主键，再回表取完整数据。写法类似这样：

sql复制SELECT t.*
FROM order_info t
INNER JOIN (
    SELECT id
    FROM order_info
    WHERE user_id = 100
    ORDER BY id
    LIMIT 1000000, 20
) tmp ON t.id = tmp.id;

子查询里只查主键，扫描 100 万行主键的开销远小于把 100 万行完整记录捞出来，性能差距明显。第二种是基于排序键的游标分页：日常场景要求排序键唯一且递增，用 WHERE id > 上一次返回的最大id ORDER BY id LIMIT 20 代替 offset 分页，MySQL 顺着索引往后扫就可以了，数据再大也快。第三种是限制分页深度，比如只允许翻前面几十页，超过就提示用户缩小筛选范围，这虽然不太“优雅”，但在很多互联网业务里是务实的妥协。

3.3 隐式类型转换和函数操作：SQL 写法里的隐形杀手

这类问题我在 3.2 提到过具体场景，但值得展开说清楚原因。MySQL 在比较 varchar 和数字时，会把 varchar 转成数字进行比较，导致索引列被隐式函数化。where order_no = 202401010001 如果 order_no 是 varchar，MySQL 会尝试把 order_no 转为数字，每一行都做一次转换，索引自然失效。我自己排查过一条线上慢 SQL，就是因为代码里订单号传成了数字类型，执行计划从 ref 变成了 ALL，修复方式就是传字符串参数，语句没变，性能立刻恢复。

另一个容易被忽略的是字符集不一致。两个表 join 时，如果关联字段的字符集不同，MySQL 会在连接时做隐式转换，同样会导致关联字段无法走索引。建表时把所有表的字符集统一成 utf8mb4，能省掉很多类似的坑。还有排序规则 collation 不一致也会出问题，我一般建议团队在建表规范里直接定死字符集和排序规则，从源头杜绝。

3.4 Join 优化：小表驱动大表，关联字段一定要有索引

一条 join 查询的性能，很大程度上取决于驱动表是谁、被驱动表的关联字段有没有索引。MySQL 优化器默认会倾向于用小表驱动大表，因为这样每扫描一行小表，去大表里查询时都有索引可用。但在实际场景中，优化器经常选错驱动表，这时可以用 STRAIGHT_JOIN 强制指定连接顺序，执行计划里的连接顺序和 SQL 写法一致。

比如订单表和用户表关联，订单表有 5000 万行，用户表 100 万行。SELECT * FROM order_info o JOIN user u ON o.user_id = u.id WHERE o.status = 1，合理情况是用筛选后的订单子集去驱动用户表，每次在用户表主键上等值查找。如果执行计划显示反过来，用户表全表扫作为驱动，那就有可能触发全表扫描风险。用 STRAIGHT_JOIN 强制顺序，通常能解决问题，但也要注意它会影响所有执行环境，改之前一定要放到测试环境压测。

还有一个常见误区：用 IN 还是 EXISTS。MySQL 5.6 之后的优化器有一定能力做半连接改写，很多时候两者执行计划差别不大，更关键的是子查询里面是否命中索引、外层表是否小。我习惯的写法是：外层表数据量小用 IN，内层子查询数据量小用 EXISTS。但这个经验需要结合实际测试，别盲信。

3.5 几条高频慢SQL的改写范例

单纯讲理论容易记不住，我整理几个实际项目里最常见的慢 SQL 改写案例，可以直接参考。

案例一：统计用户待处理订单数。原写法是 SELECT COUNT(*) FROM order_info WHERE user_id = 100 AND status = 0，这个其实没什么问题，但如果订单表有 5000 万行，每次统计要扫大量索引。常见优化是在冗余一份统计数字段或单独建一张计数表，订单状态变更时同步更新，读的时候直接查计数，避免每次实时统计扫描。

案例二：用子查询取每个用户最新订单。原写法依赖相关子查询，性能一般都不好：

sql复制SELECT * FROM order_info o
WHERE o.create_time = (
    SELECT MAX(create_time) FROM order_info
    WHERE user_id = o.user_id
);

这种写法对每一行外层订单都执行一次子查询，性能极差。改写思路是先用窗口函数或者临时表查出每个用户最大的 create_time，再关联原表：

sql复制SELECT o.* FROM order_info o
INNER JOIN (
    SELECT user_id, MAX(create_time) AS max_time
    FROM order_info
    GROUP BY user_id
) tmp ON o.user_id = tmp.user_id AND o.create_time = tmp.max_time;

案例三：范围查询习惯。很多同学条件里写 where create_time between '2024-01-01' and '2024-12-31 23:59:59'，这种没问题，但更稳妥的是写成 >= '2024-01-01' and < '2025-01-01'，语义更清晰，也能避免边界值的精度问题。

4. 分库分表：什么时候做、怎么做、怎么避坑

4.1 分库分表不是银弹，先判断是否真的需要

分库分表是 MySQL 优化里最“重”的一步，我一直建议把它当作最后手段。判断要不要分库分表，核心指标不是“表有多少行”，而是“单表是否已经让索引和 SQL 无法正常工作”。比如写入持续变慢，单表锁竞争加剧；或者主键自增达到上限风险；或者单表数据量过大，索引缓存放不下，内存命中率严重下降；这些才是分库分表的合理触发条件。

我见过一个极端案例：某业务表只有 800 万行，但被团队提前分成了 64 张表，结果每次报表统计都要跨 64 张表聚合，一个简单查询被拆成 64 个查询再合并，反而更慢。分库分表带来的收益是写入扩展性和单表数据量可控，代价是查询复杂度大幅上升。如果你的业务主要是单点查询和范围查询，单表 1000 万行以内，优化索引和 SQL 完全够用，别急着分。

4.2 垂直拆分和水平拆分怎么选

分库分表分成两种思路。垂直拆分是按业务模块拆：把用户信息、订单数据、支付流水放到不同的库或不同的表，减少单库连接数和 IO 压力。这种拆分对业务侵入较小，通常发生在多模块共用同一个库的时候，逻辑上把大库拆成小库，性能提升明显，但同时也会引入跨库查询的问题。

水平拆分是按数据行拆分：把同一张表的数据按照一定规则分散到多张结构相同的表里，比如订单表按用户 ID 哈希分成 64 张表。水平拆分能解决单表数据量过大的问题，但查询模式直接受影响。比如按用户 ID 分片，那 user_id = 100 的查询会非常快，但如果一个运营人员想按商家查订单，就要把所有分片都扫一遍，性能很可能不比之前好。

我的建议是优先做垂直拆分，把不同业务域的数据物理隔离，然后再评估水平拆分的必要性。如果确实到了水平拆分那一步，分片键的选择必须基于最核心的查询场景，而不是拍脑袋决定。

4.3 分片键设计与全局ID方案

分片键是整个分库分表方案里最关键的决策，因为它直接决定了哪些查询能定位到单表。选分片键的原则是：让高频查询能够带上这个字段，从而避免全分片扫描。订单表最常用的查询有两种：按用户查我的订单、按订单号查订单详情。如果数据量大到必须分表，一般有两种选择——按 user_id 分片，用户查询友好，但订单号查询就得记录映射关系；或者按订单号分片，订单详情查询友好，但用户查询需要先通过用户索引找到订单号列表。无论怎么选，都逃不开要做一个“映射表”或“冗余索引表”来支持另一个维度。

分片方式常见的是哈希分片和范围分片。哈希分片用 user_id % 分片数 或一致性哈希来决定数据落到哪张表，优点是数据分布均匀，缺点是新增分片时数据迁移麻烦；范围分片按时间或 ID 范围划分，比如按月分表，优点是天然支持归档和按时间范围查询，缺点是热点数据可能集中在最新一张表。从工程实践来看，时序数据适合用时间范围分片，用户类数据适合用哈希分片。

分库分表之后，原来的 MySQL 自增主键不能用了，因为多张表各自生成的自增 ID 一定会冲突。我在项目里最常用的方案是雪花算法（Snowflake）。一个 64 位的 ID 由时间戳、机器 ID、序列号组成，生成效率高，趋势递增，对索引友好。也可以用数据库号段模式：每次从一张单独的表里取一批 ID 段，然后由应用层分发，性能也很稳定。需要注意的是，无论用哪种方案，全局 ID 必须有序递增或趋势递增，否则新插入的数据主键乱序，B+ 树需要频繁页分裂，写入性能会明显下降。

4.4 跨库Join和分布式事务：分完之后的硬骨头

分库分表之后，原先简单的 join 查询变得很棘手：数据可能分布在不同的库甚至不同的机器上，数据库层面无法直接关联。现实的做法有三种。第一种是字段冗余，比如订单表里直接冗余用户昵称，下单时写入，查询时直接用，避免 join 用户表；第二种是应用层组装，先查订单，再根据订单里的用户 ID 批量查用户，最后在代码里把数据拼起来；第三种是 CQRS 思路，把报表、聚合统计等查询单独同步到分析库或搜索引擎，通过事件驱动保持数据一致。

分布式事务也一样。分库之后，同一笔业务可能涉及多个库的数据写入，单库事务失效了。常见方案有本地消息表、消息队列的事务消息、Seata 这类分布式事务框架。我的经验是：能通过业务设计规避的就不要引入分布式事务。比如把强一致的需求尽量收敛到同一个分片内，或者用“先发消息、异步重试、最终对账”的方式接受最终一致性。分布式事务不是不能用，而是成本很高，在业务早期没必要为了理论上的“完美”把自己拖进复杂度过高的泥潭。

4.5 中间件与直连方案的取舍

落地分库分表方案时，通常会面临选型问题。应用层中间件方面，ShardingSphere-JDBC 是最常见的选择，它以 jar 包的形式嵌入应用，应用直接连接各个分片数据库，路由逻辑在代码里完成，性能损耗小，适合大多数 Java 项目。ShardingSphere-Proxy 则是一个独立代理层，应用通过 MySQL 协议连它，由代理转发到后端分片库，适合非 Java 技术栈或者想对应用透明地改造，但多了一层网络转发，性能会有损耗。

自研路由方案也见过不少团队在用，主要是简单场景，比如在 DAO 层根据分片键手动拼表名。优点是灵活、无额外依赖，缺点是规则一旦复杂，维护成本非常高。我的建议是：如果团队规模不大，别自研分库分表框架，直接上 ShardingSphere-JDBC，它把 SQL 解析、路由、结果合并都封装好了，而且社区资料丰富，踩坑有人帮着趟过。部署时记得把逻辑表和物理表的映射配置统一管理，不要散落在各个服务里。

5. 问题排查与性能优化经验速查

5.1 优化优先级：索引、SQL、架构、硬件

很多开发收到慢查询告警后，第一反应是加机器、加缓存、改配置，但我的实践经验告诉我，优化顺序应该是：先看索引，再改 SQL，然后考虑架构层面，最后才是硬件和配置。索引和 SQL 的优化是零成本或低成本的，改一行代码就能解决问题；架构调整比如分库分表、引入缓存，周期长，风险高；直接上硬件，比如扩容 CPU、换 SSD，确实能带来一段时间的“无脑缓存”，但掩盖的是技术债，后续迟早要还。

我自己的线上排查标准流程是这样的：第一步，打开慢查询日志和性能监控，找到具体哪些 SQL 超过了阈值；第二步，对这些 SQL 跑 Explain，对照 type、rows、Extra 定位问题；第三步，针对索引缺失问题直接加索引；第四步，SQL 写法有问题，结合业务逻辑改写；第五步，如果同一个请求触发了大量 SQL，看是否需要合并或缓存化；第六步，如果所有单点查询都很快，但整库压力还是大，再考虑读写分离或分库分表。这套流程走下来，线上 90% 的问题都能在前四步结束。

5.2 优化过程中最容易踩的几个坑

第一个坑是索引越多越好。这个前面提过，索引会拖慢写入，还会占用大量磁盘空间。很多业务表一张表七八个索引，实际查询只有两三条路径，绝大多数索引根本没用上。我建议每季度做一次索引体检，用 sys.schema_unused_indexes 找出超过 30 天没被使用的索引，跟业务确认后删除，写入性能一般都会有可感知的提升。

第二个坑是过早引入缓存。MySQL 本身就是缓存很强大的数据库，InnoDB 的 buffer pool 能把高频数据和索引长期放在内存里。如果还没确认慢查询是不是索引问题，就先加 Redis，往往只是把问题掩盖了：Cache 击穿、雪崩、一致性这些新问题接踵而至，SQL 依然慢，系统反而更不稳定。

第三个坑是不更新统计信息。表结构变了、数据量翻了倍，统计信息不更新，优化器可能一直用旧的行数估算，选择错误的执行计划。定期 ANALYZE TABLE 看起来不起眼，但性价比极高，属于“做一次受益很久”的操作。

5.3 优化效果怎么评估：性能指标和回归验证

优化完成之后，评估效果不能只看“感觉快了”。我会对比优化前后的几个核心指标：单条 SQL 的响应时间、Explain 里的扫描行数、慢查询日志里同类 SQL 的出现频率、数据库 CPU 利用率、QPS 和 TPS。响应时间和扫描行数是最直观的，比如某条 SQL 从 800ms 降到 30ms，扫描行数从 500 万降到 1000，这就是一次有效的优化。

还有一个容易踩的坑：优化完一条 SQL，但同模式的 SQL 还有几十条。一定要在优化之后去慢查询日志里排查同模式的语句是否都降下来了，避免修了这条、漏了那条。另外，如果条件允许，我建议对核心 SQL 做一次全量回归，方法是收集真实环境的一段 SQL 查询记录，在测试库用新旧两版索引或 SQL 各跑一遍，对比性能差异，确保没有因为索引变更导致其他查询退化。

5.4 高频问题速查表

另外，关于 FIND_IN_SET 这类函数，单独说一句：它在 MySQL 里通常不会被优化成索引查找，因为函数内部的集合匹配逻辑让 B+ 树无法生效。业务上如果经常需要按固定集合筛选，不如把这个集合拆成独立子表或关联表，让查询条件落到普通等值匹配上，这才是正路。

最后再分享一点我自己的体会。数据库优化做了这么多年，最大的感受是：它更像是一门循证医学，而不是玄学。所有问题都有迹可循，慢查询日志、执行计划、性能监控就是你的诊断工具，索引就是你的手术刀。遇到慢查询别慌，按顺序排查，用小改动解决大问题，大部分情况下根本不需要分库分表这种“大手术”。希望这篇总结能帮你少走一点弯路，下次再遇到 MySQL 告警的时候，心里更有底。