MySQL索引优化与SQL调优：从失效场景到分库分表实战

1. MySQL 优化全景：先定位瓶颈再动手

刚接手一个业务模块时，我的第一反应不是打开看代码，而是先建好慢查询监控，把线上的真实 SQL 拉出来。做 MySQL 优化最忌讳的就是“没查清楚就动手”。有些人一听到数据库卡顿，就立刻把 innodb_buffer_pool_size 调大，或者直接琢磨分库分表，结果往往钱花了、架构复杂了，瓶颈还是原封不动。MySQL 的调优不像堆配置那么简单，它是一个从请求链路、SQL 执行计划、索引设计，再到架构拆分的系统工程。

这篇文章主要聊三件事：索引怎么建才不失效、SQL 怎么写才能高效走索引、以及什么情况下才值得引入分库分表。内容来自我对线上 MySQL 的长期调优实践，适合正在维护业务库的后端开发，也适合准备数据库面试的同学参考。无论你用的是自建 MySQL 还是云数据库，只要底层还是 InnoDB，这些思路都通用。

1.1 慢的源头其实可以细分成四层

遇到 MySQL 性能问题，我习惯先问一句：到底是哪一层慢？答案可以从四层去找。

第一层是客户端到服务端的网络与连接。连接数打满，或者 wait_timeout 设置不合理，会导致新请求在获取连接阶段就排队。表现在监控图上，就是“线程数飙升”，但 CPU 和磁盘都不高，SQL 本身也很快。第二层是 MySQL Server 层的 SQL 解析与优化。一个写得很烂的 SQL，比如 SELECT * 配上一堆不做筛选的 JOIN，可能把优化器直接难住，选错索引甚至全表扫描。第三层是存储引擎层。InnoDB 的锁竞争、脏页刷新、undo log 膨胀，以及索引页的随机 IO，都会让单条 SQL 等锁或者等 IO。第四层是服务器硬件与文件系统。磁盘延迟高、swap 开始使用、内存不足，都会让数据库整体性能断崖式下跌。

我把这四层按优先级排列，给自己的规则是：先解决 SQL，再看参数，然后检查架构。因为 SQL 的优化成本最低、收益最直接，且不需要改动任何部署结构。分库分表这种大动作，一定是确认单库单表确实到了物理极限之后才考虑。

1.2 一条可复用的优化推进顺序

有一段时间我处理过一个订单查询接口，白天高峰期 P99 延时从 80ms 一路涨到 2 秒，报警一直在响。我没有先去改数据库配置，而是先开慢查询日志，又用 performance_schema 采样了当时的活跃会话，结果发现几个问题叠加在一起：一张 3000 万行的订单表缺少有效的联合索引，一个高频查询在用 ORDER BY create_time DESC LIMIT 10 做深分页，还有几处业务代码在循环里逐条执行 UPDATE。

我实际执行的优化顺序是三条线同时走，但优先级分明。先在索引层面补联合索引，立刻解决了大部分点查；再改深分页 SQL 的写法，把延时降下来；最后处理循环更新，改为按主键批量更新。这个过程没有对 MySQL 配置文件做任何大改动，接口 P99 就回落到 60ms。这说明很多性能问题不是“参数不够好”，而是数据库没有拿到合适的执行路径。

所以，下面展开讲三个层面：索引为什么这么关键，SQL 怎么写才能配合索引，分库分表又该怎么判断时机。

2. 索引优化：走对路比建得多更重要

索引可以说是 MySQL 优化里杠杆率最高的手段。建对了索引，一条查询可以从秒级降到毫秒级；建错了或者建多了，不仅写放大增加，还会占用大量内存。有些人习惯给每个字段都加索引，看到哪个查询慢就加哪个索引，最后一张表有十几个索引，写入速度明显变慢，这种做法后续维护成本极高。

2.1 为什么是 B+ 树，而不是别的结构

要搞清楚索引怎么用，先得明白 MySQL 为什么选用 B+ 树。数据库数据存在磁盘上，IO 是按页读取的，InnoDB 默认一个页是 16KB。B+ 树的内部节点只存索引键和指针，不存实际数据，这样单个页能容纳大量索引项，树的高度通常只有 3 到 4 层。意思是，即使表里有上千万行数据，从根节点走到叶子节点，大体也就三次磁盘 IO，效率非常高。

对比来看，哈希索引虽然等值查询能达到 O(1)，但它不支持范围查询，也不支持排序，所以 InnoDB 默认还是 B+ 树。红黑树是内存数据结构，树高比 B+ 树更高，如果作为磁盘索引，每次查找都会产生更多次磁盘随机 IO，不适合大规模数据。B+ 树的叶子节点还有一个特点，数据之间通过指针顺序相连，做范围查询时能顺着叶子节点一路向后扫描，这是它被数据库选中的重要原因。

InnoDB 的主键索引又叫聚簇索引，叶子节点直接存整行数据。二级索引的叶子节点存的是主键值，这就是所谓“回表”的来源。假如你的查询条件是 WHERE name = '张三'，而 name 上只有二级索引，过程是先到二级索引找到主键，再拿主键回到主键索引取整行。如果这个步骤发生几千甚至几万次，性能自然会下降。解决办法就是覆盖索引，让二级索引里包含查询需要的所有字段。

2.2 主键别用随机 UUID，自增主键的天然优势

关于主键索引，我踩过不少坑。曾经有人把 UUID 字符串直接作为主键，结果写入量一大，InnoDB 插入就频繁触发页分裂。原因很简单：主键是聚簇索引，新数据如果落在已有页的中间位置，InnoDB 为了维护有序性，要把页拆开并移动数据，造成大量随机写。而自增主键会把新记录追加到索引末尾，写入基本是顺序的，页分裂概率小很多，这也是“为什么 MySQL 推荐使用自增主键”的根本原因。

当然，分库分表场景里自增主键会失效，这是后话。如果你用 UUID 做业务标识，我建议把 UUID 当作普通字段，再加一个雪花算法生成的 BIGINT 作为主键。雪花 ID 是趋势递增的，既保证了全局唯一，又不会导致聚簇索引随机写。

2.3 联合索引、最左前缀与索引下推

mysql 索引下推是指什么 是很多人在搜索时经常看到的问题。我先说结论：索引下推（Index Condition Pushdown，ICP）是 MySQL 在二级索引上做条件过滤的优化。没有 ICP 之前，存储引擎根据索引只能定位到一条条记录，然后一条条回表再让 Server 层过滤其他条件。开启 ICP 之后，如果联合索引里包含了过滤条件涉及的字段，存储引擎在读取索引记录时就会顺手过滤掉不符合条件的记录，减少回表次数。

举例最直观。假设表里有联合索引 (name, age)，查询是：

sql复制SELECT * FROM user WHERE name LIKE '张%' AND age = 30;

不开启 ICP 时，存储引擎先用 name LIKE '张%' 拿到一批主键，再逐条回表查全行，然后 Server 层再过滤 age = 30。开启 ICP 之后，InnoDB 在读取索引的叶子节点时，会直接用索引里的 age 字段做判断，不符合条件的根本不回表。名字前缀匹配出来可能有上万条，但age = 30过滤后只剩几百条，回表次数大幅降低。

联合索引的另一个重点是“最左前缀原则”。(a, b, c) 联合索引能高效支持 a、a,b、a,b,c 这几种查询条件，但如果你上来就用 b = 1，这个索引基本发挥不了作用。原因是 B+ 树的排序是先按第一个字段排，再按第二个字段排，跳过第一列直接过滤第二列，相当于要扫描整棵索引树的一部分，效率极低。

所以设计联合索引时，通常把等值条件字段放前面，把区分度高的字段放前面，把范围查询字段尽量放后面，不过度追求“把所有查询都覆盖到”。MySQL 8.0 支持了索引跳跃扫描，能在一定条件下利用 (a, b) 索引去优化 b 单独查询的场景，但它并不稳定，不能作为主要依赖手段。

2.4 最容易踩的索引失效场景

索引失效是个老生常谈但永远有人在踩的话题。我整理了我实际遇到过、也去验证过的高频场景，写成一张速查表供参考。

举一个我处理过的隐式转换案例。有一张用户表中的 phone 字段定义为 VARCHAR(20)，业务代码里有人把查询参数写成了 Long 类型，WHERE phone = 13800001111。MySQL 优化器会把字符串字段转换为数值再比较，导致索引失效，上千万行的表查询耗时从几十毫秒变成 3 秒多。我们当时的修复方案很朴素：应用层把手机号参数改成 String 类型，SQL 传参保持字符型，索引立刻恢复正常。

关于 FIND_IN_SET 能不能走索引的问题，我也直接说结论：在 MySQL 常规实现里，FIND_IN_SET(col, '1,2,3') 是对索引列做函数调用，基本无法走索引。如果业务需要频繁按逗号分隔的标签筛选，最佳方案是拆成关联表，比如用户标签关系表，再加联合唯一索引；不要试图在文本字段上做高效过滤。

3. SQL 优化：看懂执行计划再动手写 SQL

索引是底子，SQL 是上层建筑。同样的查询需求，换个写法，执行计划天差地别。SQL 优化并不是背几个“避免 SELECT *”的口诀就够了，而是学会看懂 MySQL 给出执行计划，判断它为什么选择全表扫而不是走索引。我曾经因为优化器“选错索引”排查过整整一周，最后发现是统计信息过旧，一张千万行的表用 ANALYZE TABLE 重新统计后，执行计划立刻从一个普通索引切换到另一个更合适的索引，问题迎刃而解。

3.1 把慢查询找出来，别等用户来告诉你

业务系统如果没有主动采集慢查询，往往等到用户投诉页面转圈才发现数据库出问题。推荐的做法是打开 MySQL 的慢查询日志：

ini复制slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON

long_query_time = 1 表示超过 1 秒的 SQL 都会被记录。如果系统已经很大，日志刷得飞快，可以调成 2 或 3 秒先排查最严重的。另外，log_queries_not_using_indexes 会把没有走索引的 SQL 也记下来，这个开关建议开启，因为它能提前暴露索引设计的问题，而不是等问题积累到用户不可接受才动手。

定位到慢 SQL 之后，使用 EXPLAIN 看执行计划是基本功。以一条被业务告警盯上的查询为例：

sql复制EXPLAIN SELECT id, order_no, status
FROM order_202501
WHERE user_id = 12345
ORDER BY create_time DESC
LIMIT 20;

关注 type 字段，它的好差排序大概是 system > const > eq_ref > ref > range > index > ALL。如果你的查询落在 ALL，意味着它在全表扫描。再看 key 字段表示最终使用了哪个索引，rows 表示预估扫描行数，Extra 里出现 Using filesort 代表 MySQL 需要用额外的排序操作，可能产生临时文件，这是性能大忌。

3.2 深分页、SELECT * 与“一条条处理

深分页是我在业务代码里见到频率最高的性能杀手。分页功能必然存在，但很多人直接把 LIMIT 1000000, 20 写到线上。MySQL 执行这种 SQL 时，会先把前 1000020 行数据都查出来，再丢弃前 1000000 行，这种浪费在小数据量时看不出来，一旦主表有几百万行，接口就会超时。

改造深分页有一个通用的“延迟关联”思路。先不要查明细数据，而是通过覆盖索引快速定位目标主键，然后再关联回原表取完整记录：

sql复制SELECT t.id, t.order_no, t.status
FROM order_202501 t
INNER JOIN (
    SELECT id
    FROM order_202501
    WHERE user_id = 12345
    ORDER BY create_time DESC
    LIMIT 1000000, 20
) tmp ON t.id = tmp.id
ORDER BY t.create_time DESC;

如果产品列表本身有条件可以做成“上一页/下一页”模式，尽量用 WHERE create_time < 上一页最大时间 代替 OFFSET 翻页，这不仅避免了深分页，还更符合用户场景。不过我理解现实业务里很多产品需要直接跳页，这时使用延迟关联是更稳妥的方案。

提到 SELECT *，我见过不少新人觉得这是偷懒写法的重灾区。SELECT * 最大的问题不只是多返回了字段，而是二级索引里没有这些字段时，MySQL 必须逐条回表，覆盖索引失效。比如一行有 40 个字段，但页面上只展示其中 5 个，把这个 5 个字段写进 SELECT 中，再联合索引覆盖这些列，查询性能会有肉眼可见的提升。

另外一个致命问题是“循环里逐条执行 SQL”。有一次排查一个批量结转任务，业务同学在同一事务里对数百个用户逐个执行 UPDATE，每个 UPDATE 都走主键。看起来没问题，但事务持有大量行锁，而且网络往返次数高，最终整体耗时长、锁竞争剧烈。改成 CASE WHEN 批量 UPDATE，或者用临时表做多表更新，事务时间缩短到原来的几十分之一。

3.3 注意 SQL 注入的前提：别用拼接 SQL

SQL 绕过和注入属于安全话题，但这和 SQL 优化其实是同一枚硬币的两面。某些旧代码喜欢把用户输入直接拼进 SQL：

sql复制SELECT * FROM user WHERE username = 'admin' AND password = 'xxx'

用户名一旦传入 ' OR '1'='1，组合出的条件就成了永真式，用户就能绕过程序校验直接登录。防止这种问题不是上线一个 WAF 就万事大吉，而是从编码源头杜绝拼接 SQL。我现在的团队有一个硬性要求：所有数据库操作必须使用预编译参数或 ORM 的参数绑定机制。参数化查询不仅安全，还会让 MySQL 更容易复用执行计划，减少重复解析的 CPU 开销。所以从另一个角度看，这条规范对性能也是一种保护。

4. 分库分表：压力到了这一步，先别急着拆

分库分表常被当成数据库优化的终极方案，但我更愿意把它看成最后一层“兜底”。引入分库分表之前，一定要先问三个问题：单表数据量真的到瓶颈了吗？业务查询能否按分片键收敛？团队愿意承担多出来的架构复杂度吗？如果没有想清楚这些问题就拆表，你会发现分布式查询、分布式事务、全局主键等问题接踵而来，后面很长一段时间都在为拆分买单。

4.1 什么时候才值得考虑分库分表

“多少行数据需要分库分表”没有固定标准，因为不同业务的行宽差别很大。一个经验值是：单表超过 2000 万行，且查询延迟开始出现明显抖动、索引维护成本变高时，就要认真考虑优化方案了。但也有例外，一张表虽然只有 500 万行，可每行包含大量 TEXT/BLOB 字段，实际存储超过 50GB，热点扫描依然会让 IO 成为瓶颈。

更关键的是看“写入增长曲线”和“查询模式”。假设订单表每天新增 20 万行，一年下来就是 7300 万行，两年后 1.5 亿行，即便索引都建好了，写入时的页分裂、binlog 同步、备份恢复都会拖累整体性能。同时如果业务查询主要按用户维度访问，做成 user_id 分片，单分片的数据量能控制在可接受范围，分库分表才有实操价值。

我还想强调一点：分库分表不是解决“查询写不好”的遮羞布。如果一张 500 万行的表，因为缺少索引导致全表扫描要 10 秒，你要做的不是拆表，而是补索引、改 SQL。架构拆分应当发生在“所有单库优化手段都已经穷尽”之后，否则问题只会被拆分掩盖，等到数据量更大时会再次爆发，且爆发的半径更大。

4.2 分表和分区的区别：别把分区当分表

很多人一聊分库分表就把“分表”和“分区”混为一谈。MySQL 的分区表在逻辑上仍然是一张表，底层存储按分区规则拆成多个文件。比如创建一个按月份 RANGE 分区的订单表：

sql复制CREATE TABLE order_2025 (
    id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2),
    create_time DATETIME NOT NULL,
    PRIMARY KEY (id, create_time)
) PARTITION BY RANGE (YEAR(create_time) * 100 + MONTH(create_time)) (
    PARTITION p202501 VALUES LESS THAN (202502),
    PARTITION p202502 VALUES LESS THAN (202503),
    PARTITION p202503 VALUES LESS THAN (202504)
);

分区表在应用层无须感知，还能通过 DROP PARTITION 快速清理历史数据，这是它的优势。但它毕竟是单库内的存储组织方式，不能突破单实例的 CPU、内存和 IO 上限。真正到了需要水平扩展的阶段，分区帮不上忙，必须做分库分表。

分库分表按照方向不同，又分为垂直拆分和水平拆分。垂直拆分类似“按业务域切表”，把一些不常用的大字段拆到扩展表，或者把订单库和用户库拆到不同实例，减轻单库压力。水平拆分才是大家口中的分表，把同一张逻辑表的数据按规则分发到多个物理表，比如 order_0、order_1 一直到 order_15。写业务代码时无法直接查原表名，必须通过分库分表中间件做路由。

4.3 分片键选错，后果比不分还严重

分表的关键在于路由算法，而路由算法又取决于分片键。按用户 ID 分片是最常见的做法，如 order 表按 user_id % 16 分到 16 张表。这种方式的好处是同一用户的所有订单都在同一物理表上，查询“我的订单”非常自然，且各分片数据基本均匀。缺点也很明显：如果将来要从 16 张表扩容到 32 张表，user_id % 16 的规则无法平滑迁移，所有数据都需要重排。

另一种是按订单 ID 范围分片，比如每 5000 万条订单放一张表。这种方式有利于按时间归档，却容易产生热点，最新数据通常集中在最后一个分片，写入压力依然集中。一致性哈希则更常见于缓存中间件，MySQL 数据分片使用起来基本是 hibernate shards 或 proxy 的算法能力，普通团队实现成本偏高。

我的建议是，能按业务自然维度收敛就按业务维度拆。例如平台类系统用户查询订单、商家查询订单并存，可以考虑订单表数据冗余或者用“商家订单分片”与“用户订单分片”两套表同步维护，虽然会有额外存储成本，但能保证主要查询场景都不跨分片。设计分片键前，建议把所有高频查询条件整理成表格，如果一个表的所有高频查询都无法通过某一字段路由，那么这个表可能就不适合做简单的分片。

分库分表之后，原来单表上的 AUTO_INCREMENT 主键会失效。分布式环境下每个分片都有自己的起始自增值，最终会冲突。业界通常使用雪花算法生成全局唯一 ID，或者用 Redis 分配器、数据库号段模式生成连续 ID。核心目标只有一个：无论数据落到哪个分片，主键全局唯一且尽量趋势递增，从而避免写入分片内部的聚簇索引频繁分裂。

4.4 中间件怎么选：透明代理 与 客户端模式

选中间件时，团队投入的技术栈和运维能力很关键。ShardingSphere 有客户端模式和代理模式两个形态。客户端模式的本质是应用层通过数据源增强，自动感知分片规则，对已有的 Spring 项目侵入较小；代理模式则是单独部署一个中间层服务，应用连它就像连一个普通 MySQL，业务代码无须大改，但中间层本身会成为新的瓶颈和运维节点。MyCat 这类代理模式也很经典，适合团队有专门的 DBA 或中间件团队维护，但在复杂的分布式事务场景下仍然面临不小的挑战。

不管选哪种中间件，迁移不是一蹴而就的。稳妥做法是先引入读写分离，再逐步把单表切为多表。新老系统并行跑一段时间，通过影子表对比数据，确认分片结果没有偏差，再切流量。当年我们切换订单表时，几乎是用了一个周末的凌晨，准备好回滚脚本，流量逐步放量到 10%、30%、100%，每到一个比例就停顿观察数据库的慢查询和主从延迟。

4.5 拆完之后，代价才刚开始

分库分表后最难受的问题不是 SQL 语法变了，而是原先在单表上很自然的能力分裂了。比如多表 JOIN，orders 表和 order_items 表如果按不同键分片，关联时可能跨越多个物理库，单条 JOIN 就会退化成多次查询再在应用层聚合；再比如唯一性约束原来靠数据库就能兜底，拆分后只能依赖全局 ID 方案或者额外维护一张约束表。

分布式事务是另一个绕不开的坎。如果一个业务操作同时修改了不同分片的数据，不能再用数据库本地事务保证原子性。市面上常见的 Seata AT 模式、TCC 模式以及本地消息表都可以用，但它们都有吞吐层面的取舍。所以我一般建议，在业务建模时就尽量让事务边界落在同一分片上。对于实在无法避免跨分片写的情况，宁可接受最终一致性，也不要强行引入强事务方案，导致系统过度复杂。

这里要特别提一句，引入分库分表以后，跨分片的分页排序是一件非常难做的事。单库时 ORDER BY create_time LIMIT 20 只需要排序一次，分片后中间的 proxy 必须把每个分片的前 N 条都取回来，再在内存合并排序，翻页越深，中间内存开销越大。因此，需要“全局排行榜”或者“全量跨分片查询”的业务，要么在设计阶段就准备好宽表方案，要么引入搜索索引组件，而不是在数据分散后指望 MySQL 层面还有简单解法。

5. 避坑实录：从一次索引失效到一套优化流程

整个优化过程中，我强烈建议把每一步操作都记录下来。这不仅能帮助你沉淀方法论，还能在问题复发时快速定位。下面分享一次比较典型的索引失效排查过程，以及我常用的监控和回归验证方法。

5.1 案例复盘：DATEDIFF 函数让索引彻底“罢工”

去年有张流水表 trade_log，体量到了 8000 万行。某天业务方反馈一个统计报表接口变慢，查询条件是这样：

sql复制SELECT user_id, SUM(amount)
FROM trade_log
WHERE DATEDIFF(create_time, '2025-03-01') >= 0
  AND DATEDIFF(create_time, '2025-03-31') <= 0
GROUP BY user_id;

初看没什么毛病，开发还专门给 create_time 建了索引。但执行计划显示该 SQL 走了全表扫描。原因就是 DATEDIFF(create_time, ...) 把索引列放进了函数，MySQL 无法直接按 create_time 做范围扫描。改法很简单，把函数放到参数一侧，等价写成：

sql复制SELECT user_id, SUM(amount)
FROM trade_log
WHERE create_time >= '2025-03-01 00:00:00'
  AND create_time < '2025-04-01 00:00:00'
GROUP BY user_id;

改写后，SQL 走上了 create_time 索引，在同样体量数据下，统计耗时从几百秒降到个位数秒。这个案例足以说明一个原则：在对索引列做任何运算前，先想一想能不能把运算转移到值一侧。大多数 MySQL 优化规则，本质上都是为了让索引列“裸奔”在比较条件中，这样才能充分利用 B+ 树的顺序查找能力。

5.2 排查数据库隐患的日常工具与命令

日常巡检我会主要关注几组指标：CPU 使用率、磁盘 IO 延迟、活跃连接数、慢查询数量、主从复制延迟。使用 sys 库可以快速找到最慢的一组 SQL：

sql复制SELECT * FROM sys.statements_with_runtimes_in_95th_percentile ORDER BY avg_latency DESC LIMIT 10;

performance_schema 是 MySQL 自带的能力，不用额外安装。如果某台实例最近 CPU 飙高，我会先看有没有大量“Sending data”状态的线程，再查是否出现了锁等待：

sql复制SELECT * FROM performance_schema.data_lock_waits\G

锁等待导致的现象通常是，数据库整体明明不慢，但特定业务线程卡住不动，前端表现为所有请求都在堆积。这类问题通过查看 innodb_trx 能快速识别出哪个长事务没有提交。

如果用的是自建 MySQL，平时最好保持开启 slow_query_log，并把 long_query_time 设为 1 秒，再用 pt-query-digest 做慢日志聚合，它能按平均耗时、出现次数排序，直接暴露当前系统里“最值得优化”的 Top SQL。如果使用的是云数据库，通常控制台自带 SQL 洞察功能，可以长期观察 SQL 延迟曲线，这种持续性的数据比单次 EXPLAIN 更有参考价值。

5.3 优化上线前，做好延迟与并发压测对比

我总是强调“没有对比不能叫优化”。改索引、改 SQL 前，先留下原版本的压测数据，压测结果至少包括平均延时、TP99 延时和吞吐量。一个简单的对比案例，是接口优化前 TP99 为 620ms，压测并发 100 时成功率只有 99.2%；优化后 TP99 降到 90ms，并发 100 时成功率 100%。没有这些数字，运维验收和团队评审都很难给出让人信服的结论。

压测工具可以用 sysbench 或者 JMeter。sysbench 更偏底层，适合直接对单表做读写压测；JMeter 更适合测试业务接口整体链路。如果只验证某个 SQL，可以在测试环境先 EXPLAIN，再实际执行多次取平均值。测试环境的数据量必须和生产保持同一数量级，否则索引的选择性完全不同，压测结果没有意义。

回归验证的重点还包括写入性能。因为加索引本质上是以写放大换取读优化，如果一张表频繁有 INSERT/UPDATE，新索引会拖慢写入。所以上线前我会统计写接口的耗时变化，如果 DML 的 P99 延迟上升超过 15%，就要重新评估是否需要保留某些低效索引。

我个人的体验是，MySQL 优化更像一场持续迭代，没有一劳永逸的解药。每次业务上线新功能，数据规模翻倍，或者查询模式变化，都要重新审视当时的索引和 SQL。与其等到线上报警再熬夜排查，不如在需求评审阶段就让那些明显会扫表的 SQL 暴露出来。这样下来，大部分性能问题都不会发展到需要分库分表的程度。