MySQL千万级数据表优化实战：索引设计、慢SQL与架构取舍

搞过几年MySQL的人，基本都会碰到“表越来越大、接口越来越慢”的阶段。前阵子我接手一个核心业务表，数据量过了8000万，单表磁盘占用快50GB，线上几次慢查询直接把数据库CPU打到80%以上，接口超时告警响了一整晚。那次优化前后搞了大概两周，算是把千万级到亿级数据表的优化路子彻底走了一遍。这篇就把我踩过的坑、用过的方案、筛选后的经验完整写出来，涉及的思路和SQL示例都是可以直接拿去用的。

1. 千万级数据表优化：先讲清楚从哪儿下手

先说个反直觉的结论：数据量到千万级，很多问题已经不是单条SQL能解决的，而是“表设计 + 索引 + 查询习惯 + 架构取舍”共同作用的结果。有些表看着字段特别全、索引特别多，性能照样拉胯；有些表没加几个索引，但每条SQL都命中到点子上，千万级也跑得轻轻松松。

1.1 一个真实场景：8000万行的订单表

我之前处理的这张订单表，结构上其实不算复杂，核心字段就这些：

sql复制CREATE TABLE `orders` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL,
  `user_id` bigint NOT NULL,
  `product_id` bigint NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  `status` tinyint NOT NULL DEFAULT '0',
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_created_at` (`created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

线上慢查询集中在这几类场景：

• 按 user_id + created_at 时间段分页查订单，排序字段是 created_at DESC；
• 后台运营按月汇总金额，直接 SUM(amount) WHERE status=... AND created_at BETWEEN ...；
• 按 order_no 精确查单，但因为当时 order_no 没建唯一索引，走了全表扫描。

这几类SQL在百万级时还能忍，到了千万级就是灾难。第一优先级是搞清楚瓶颈是什么，别一上来就想着分库分表。

1.2 诊断工具先用起来：三条命令帮你定位

优化不能拍脑袋。我建议任何优化动作之前，先把下面三样东西拉出来看：

• 慢查询日志：确认当前是否开启，以及阈值设置是否合理；建议生产环境 long_query_time=1，执行超过1秒的SQL全部记录下来；
• SHOW GLOBAL STATUS：看 Threads_connected、Table_locks_waited、Slow_queries 几个关键计数；
• EXPLAIN：对目标SQL逐个执行计划分析。

如果慢查询开关没开，先动态打开并持久化到配置文件：

ini复制[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
examine_...

改完之后重启MySQL，或者用 SET GLOBAL slow_query_log = 'ON'; 在线开启。这里要注意在线开关重启后会失效，所以配置文件和动态执行两边都要做。

注意：log_queries_not_using_indexes 打开后会记录很多连索引都没走的SQL，刚开启的一两天量会比较大，建议监控磁盘空间。

1.3 先回答四个问题再动手

我在优化前会在纸上把这张表的问题列一个清单，核心只有四个问题：

• 哪些SQL访问频率最高？把 information_schema 里的统计和业务日志对应起来，确保优化优先级正确；
• 这些SQL分别走了哪些索引？还是根本没用索引？
• 表里的数据是“热数据多”还是“历史包袱重”？比如订单表，三年前的订单根本没人查，占了全表一半空间；
• 数据增长的速度是多少？1天增长多少行、多少MB，决定你要不要提前做分区或归档。

这一步很多人会跳过，直接去加索引。但缺少全局判断，优化动作往往是拆东墙补西墙。我见过最典型的案例是：为了提升查询加了一堆单列索引，结果写放大严重，插入变慢，锁竞争加剧，反而引发更大的故障。

2. 表结构和索引设计：性能问题的第一道根因

千万级表优化，索引和表结构是主场。SQL写法再花哨，表结构设计有问题也很难救回来。这里我挑几个最值得关注的细节展开。

2.1 字段类型选不对，索引再强也白搭

一个很常见的错误是：业务表里不管什么字段都用 varchar。尤其主键和关联字段，如果排序规则没用对，走索引时会因为类型隐式转换导致索引失效。

举个例子：订单表里 user_id 是从用户服务传过来的，有时候应用层传的是字符串 "12345"，如果字段是 bigint，MySQL会自动把字符串转换成数字再比较，这个转换基本不影响索引命中，但反过来，如果字符串字段（比如 order_no varchar(64)）去和一个数字比较，MySQL会尝试把字段转成数字，结果就是索引失效。

所以字段设计上，我建议：

• 主键优先用 bigint，不要用 uuid 字符串做主键。InnoDB是聚簇索引，主键随机插入会导致页分裂频繁，写入性能断崖式下跌；
• 金额用 decimal，别用 float/double，精度问题是钱相关的致命伤；
• 状态、类型这类有限枚举值用 tinyint，别用 varchar，省空间且查询快；
• 时间字段用 datetime 还是 timestamp，主要看时区需求和年份范围，建议统一用 datetime(3)，保留毫秒对后续排查有好处。

另外字符集尽量统一 utf8mb4，别让关联字段的排序规则不一致。两张千万级表做 JOIN，关联字段一个 utf8mb4_general_ci、一个 utf8mb4_unicode_ci，MySQL对JOIN条件可能无法高效使用索引，一次关联能慢出一个数量级。

2.2 索引设计：不是越多越好，而是要覆盖查询路径

很多人对加索引的理解是：查询慢，加个索引；还慢，再换字段加。这样三个索引五个索引加下来，单表写入时每个索引都要同步更新，5个冗余索引意味着每次插入至少要写6棵树（聚簇索引 + 5棵二级索引树），性能自然惨不忍睹。

我调整订单表时，采用了三个核心复合索引替换原来零散的单列索引：

sql复制ALTER TABLE orders
  DROP INDEX idx_user_id,
  DROP INDEX idx_created_at,
  ADD INDEX idx_user_created (user_id, created_at),
  ADD INDEX idx_status_created (status, created_at);

设计依据来自对业务SQL的梳理：

• 用户端查询：WHERE user_id = ? AND created_at BETWEEN ? AND ? ORDER BY created_at DESC，此时走 idx_user_created 最合适，等值条件在左、范围条件在右，排序字段也包含在里面；
• 运营统计查询：WHERE status = ? AND created_at BETWEEN ?，此时走 idx_status_created。

那原来的单列索引能用吗？比如只保留 idx_user_id，MySQL确实可以通过索引定位到某个用户全部订单，但后续还得把 created_at 的时间过滤拉出来再逐条判断，数据量大了之后回表次数极多，性能远不如复合索引一次定位。

复合索引的顺序也有讲究，核心原则是：等值条件放前面，范围条件放后面，排序字段尽量包含在索引里，保证从左到右前缀匹配。

2.3 覆盖索引是千万级查询的隐藏利器

先看一个查询：

sql复制SELECT order_no, status, amount
FROM orders
WHERE user_id = 12345
  AND created_at >= '2024-01-01'
  AND created_at < '2024-02-01'
ORDER BY created_at DESC
LIMIT 20;

如果只有 idx_user_created (user_id, created_at)，索引能定位到数据行，但 order_no、status、amount 这三个字段不在索引里，必须每行都回主表拿一次完整数据，20行还好，如果扫描范围内有几千几万行，回表次数就爆炸。

解决办法是把查询要的字段直接塞进索引里，形成覆盖索引：

sql复制ALTER TABLE orders
  ADD INDEX idx_user_created_cover (user_id, created_at, order_no, status, amount);

虽然这是个4字段的复合索引，看起来冗余，但在高频查询场景下收益极高。因为MySQL在索引里就能拿到全部结果，完全不需要回表，磁盘I/O大幅下降。

注意：覆盖索引不要滥用。一个表索引总字段数过多会影响写入性能。一般建议只对“查询频率极高 + 字段长度小”的场景做覆盖索引，而且优先塞短字段（状态、金额），像 product_id 这种还好，但别把 order_no 这种还算可控。如果哪天想把大文本字段塞进覆盖索引，千万别做。

2.4 冗余字段和反范式设计

千万级之后，“老老实实三范式”反而会让自己很难受。比如订单列表页需要展示商品名称，如果每次都关联商品表去查，商品表再过千万级，JOIN的代价会很高。常见做法是订单表在落单时冗余一个 product_name 字段，或者把商品快照字段写进去。查询时少一次JOIN，收益肉眼可见。

这里我在实际项目里是这样权衡的：快照类冗余字段该加就加（商品名、优惠名称），因为这些信息随时间会变，业务又要显示“当时的下单数据”，冗余反而更合理；但如果是用户昵称这类高频不变信息，只存 user_id，必要时用缓存补充。

3. 慢SQL改写：从3秒到0.03秒的过程复盘

表结构和索引做好之后，如果还有慢SQL，那大概率是写法和优化器理解出现了偏差。千万级表对SQL非常敏感，同样的查询逻辑，写法不同性能天差地别。我拿一个真实案例来拆。

3.1 explain执行计划到底在看什么

先说 EXPLAIN。很多新手执行完 EXPLAIN SELECT ...，只会看 type 是不是 ALL，其他字段一概不管，这不行。我实际排查慢SQL时主要看这几个字段：

一个典型的慢SQL执行计划例子：

sql复制EXPLAIN SELECT * FROM orders 
WHERE user_id = 12345 
ORDER BY created_at DESC 
LIMIT 10;

上面索引是 idx_user_id 单列索引时，执行计划里 type=ref、rows=5000、Extra=Using filesort。虽然用上了索引，但排序还是要额外做一次，5000行还好，如果某用户订单几十万行，Using filesort 就会导致明显的延迟。优化方式就是建 (user_id, created_at) 这种复合索引，让排序也能从索引里顺序获取，执行计划里的 Extra 变成空，速度提升非常明显。

3.2 深分页场景：LIMIT 1000000是性能杀手

业务列表页常见的翻页场景，越往后越慢，核心原因在你翻到第5万页时，MySQL还得先把前5万页数据全部读出来再扔掉，整个过程大量无效I/O。

sql复制SELECT id, order_no, user_id, amount, status
FROM orders
WHERE user_id = 12345
ORDER BY id DESC
LIMIT 1000000, 20;

这条SQL在千万级表上，执行时长通常会从几十毫秒逐渐恶化到几秒。我的改造方案是范围查询代替深分页，利用上次查询结果的最大或最小ID作为下一页的边界条件：

sql复制SELECT id, order_no, user_id, amount, status
FROM orders
WHERE user_id = 12345
  AND id < 1000000   -- 上一页最后一条记录的id
ORDER BY id DESC
LIMIT 20;

这个方案的本质是把“随机跳页”变成“顺序翻页”。大多数场景用户根本不会从第1页直接跳到第50000页，所以用ID游标翻页对产品体验几乎没有影响，但数据库扫描范围被严格限制在一个很小的区间内，执行时间非常稳定。

如果产品确实需要支持“跳到任意页”，还可以用延迟关联的方式优化：

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

子查询只查主键 id，不查所有字段，InnoDB走二级索引或者主键索引扫描的开销远小于全字段回表；拿到主键后再关联回原表取完整记录，这样能显著减少回表数据量。

3.3 排序和GROUP BY优化

千万级表上，ORDER BY 和 GROUP BY 是最容易碰到的两类优化难题。对于 ORDER BY，加对了索引就不用额外排序；对于 GROUP BY，最好也能利用索引的有序性，否则MySQL会建立临时表来分组。

我当时处理过一条销售统计SQL：

sql复制SELECT user_id, DATE_FORMAT(created_at, '%Y-%m-%d') AS day, SUM(amount)
FROM orders
WHERE created_at BETWEEN '2024-06-01' AND '2024-06-30'
GROUP BY user_id, DATE_FORMAT(created_at, '%Y-%m-%d');

这种写法的问题在于，DATE_FORMAT 函数把 created_at 转换了，索引根本没法继续参与分组。千万级表上做大范围时间分组，执行起来很痛苦。

优化思路并不是强行把函数去掉，而是承认这种“任意维度自由分析”对OLTP表来说太重了。最合理的方式是：

• 提前生成一张日汇总统计表，每天定时任务把当天的汇总数据刷进去；
• 查询时直接查汇总表，避免对明细表做动辄几十万行的实时聚合。

这种思路本质上属于“以空间换时间”。做 MySQL 千万级优化，不能只盯着索引和SQL，还得知道什么时候该把实时计算转成预聚合。

经验总结：单表数据超过千万级，复杂聚合类的实时统计就应该考虑预聚合层，比如汇总表、缓存，甚至配合其他分析型引擎来做。硬扛实时大聚合，数据库迟早被打爆。

4. 千万级之后的架构手段：分区、归档、读写分离

如果做完索引和SQL优化，数据还在快速增长，单表已经五千万甚至上亿行，那就得考虑更重的优化手段了。虽然单表五千万行不一定不能用，但维护成本、备份恢复时间、加索引时的DDL锁等待都会变得无比痛苦。

4.1 分区表：什么时候用、什么时候别用

很多人一听大表就想到分区，但分区不是万能的。我做过一个用户操作日志表，数据量1.2亿行，按年分区之后效果特别好。但订单表我却没做分区，因为订单的查询模式是 user_id 等值为主，按时间范围分区帮助不到基于 user_id 的查询，反而增加了查询优化器的判断成本。

分区适合两个场景：数据有明显的时间范围维度，并且大量查询都带这个范围条件；数据清理需求明显，比如日志只保留3个月，分区后直接 DROP PARTITION 比 DELETE FROM 高效无数倍。

如果决定用RANGE分区，建表时可以这样设计：

sql复制CREATE TABLE operation_log (
  id BIGINT NOT NULL,
  user_id BIGINT NOT NULL,
  action VARCHAR(100),
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id, created_at)
)
PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2023 VALUES LESS THAN (2024),
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026)
);

注意这里有个关键点：MySQL要求分区键必须包含在主键或唯一键里面，所以订单日志表的主键如果是 id 单列，想按 created_at 分区就必须改成复合主键 (id, created_at)，这种改动在已有大表上代价很高，需要提前设计。

注意：5.7版本的MySQL对分区表的很多优化支持不够好，如果SQL查询条件不带分区键，优化器很可能扫描所有分区，结果比普通表更慢。所以分区表一定要确保核心查询条件都带上分区字段。

4.2 冷热数据归档：最实用的减负手段

如果做过数据分布分析，你会发现大多数业务表都遵循“二八定律”：80%的查询集中在最近20%的数据上。我看到某订单表三年前的历史数据占了60%表空间，但查询量不到1%，这些数据留着只会让索引变大、缓存命中率下降、备份时间变长。

最直接有效的方案就是做冷热归档。把过期数据从在线表复制到历史归档表，再从在线表删除：

sql复制-- 1. 创建归档表，结构和原表保持一致，索引可以按归档查询需求精简
CREATE TABLE orders_2023 LIKE orders;

-- 2. 批量插入归档
INSERT INTO orders_2023 
SELECT * FROM orders 
WHERE created_at < '2023-01-01' 
LIMIT 5000;

-- 3. 确认无误后从原表删除
DELETE FROM orders 
WHERE id IN (
  SELECT id FROM orders_staging WHERE created_at < '2023-01-01' LIMIT 5000
);

注意：绝对不要一次性 DELETE 几百万行。InnoDB单次大事务会带来巨大的锁开销、undo膨胀、主从延迟（如果有主从）。我实际执行时是按 LIMIT 1000~5000 分批delete，每批之间停上几百毫秒，这样既不影响线上业务，也避免产生长时间锁等待。

数据归档之后，在线数据量能减少到千万级以下，索引查询、备份、DDL都会轻松不少。旧数据并不是没用了，还可以定期导入分析库或数据仓库。

4.3 读写分离的落地条件

读写分离是个听着顺理成章、落地却挺复杂的方案。当初我在订单表上做读写分离，最大的感受是：主从延迟问题永远躲不掉。主库刚写入一条订单，从库在并发下可能还没同步过来，用户刷新马上查不到，这就是常见的“主从延迟”。

所以在MySQL千万级优化里，读写分离通常不是第一步，而是数据增长压力下选择的较高成本的方案。它的前置条件总结如下：

• 业务能容忍短时间读延迟（秒级）；
• 读流量远大于写流量，且需要横向扩展读能力；
• 已经有比较完善的数据一致性兜底机制。

如果决定走读写分离，建议在中间加一层路由组件（比如根据SQL关键字自动分发到主库或从库），或者干脆在应用层自己实现数据源切换。需要配套跟进主从延迟监控，延迟超过阈值时要及时报警。

从成本收益角度看，我个人的优化顺序是：索引优化 -> SQL改写 -> 冷热归档 -> 分区表 -> 读写分离 -> 数据分片（分库分表）。不要一上来就上分库分表，那是最重、最不可逆的手段，一定要放在最后。

5. 常见坑点与问题排查实录

优化方案落地过程中，很多坑不是优化思路不对，而是对MySQL机制理解不透彻造成的。这里集中整理几个我实际踩过、也看到其他人反复踩的典型问题。

5.1 索引失效的几种隐蔽场景

索引失效是老生常谈，但有些场景真遇到时很容易绕晕，我梳理成一张速查表供排查参考：

5.2 DDL锁等待问题：给大表加索引的教训

千万级表上做DDL操作，比小表要复杂得多。早期MySQL版本中，ALTER TABLE ADD INDEX 会锁表，线上大表直接执行，业务会瞬间阻塞。即使后来的版本支持了 ALGORITHM=INPLACE，也不能完全避免对元数据锁的依赖。

有次我心态比较急，在9000万行订单表上直接执行：

sql复制ALTER TABLE orders ADD INDEX idx_status_created (status, created_at), ALGORITHM=INPLACE, LOCK=NONE;

结果因为后台已有长事务没提交，这个DDL命令一直在等元数据锁，队列后面的所有查询全部被堵住，造成一次小型故障。后来再操作大表DDL，我统一采用三个步骤：

• 先用 pt-online-schema-change（Percona Toolkit）或 gh-ost 这类在线改表工具，降低对线上影响；
• 改之前先查一下是否有长时间运行的事务：SELECT * FROM information_schema.innodb_trx;
• 尽量选业务低峰期执行，同时设置锁等待超时时间，避免DDL卡死整个连接池。

5.3 线上优化的一次完整复盘

这里把当初订单表优化前后效果完整列出来，给各位一个感性参考：

需要诚实说明的是：优化后慢查询还是会有，比如运营临时拉数、后台导出等偶尔还是会打到订单表。这种事不该靠数据库硬扛，我额外配置了只读从库和分析库把这类查询引过去，主库压力才真正降下来。

优化的核心逻辑归纳起来就一句话：让数据在MySQL执行时，减少扫描行数、减少回表次数、减少锁的影响范围。方向对了，效果自然就出来了。

做这类优化最忌讳的是照搬网上的方案。每个表的数据分布、查询模式、写入频率完全不同，我建议你拿到一个千万级表，先花半天时间把慢查询日志、表结构和核心SQL彻底摸一遍，再选定上面合适的方案组合。很多人在这一步没耐心，急着上分库分表，最后付出巨大的架构改造成本，收益却很小。先做便宜的优化，把最核心的几条SQL打到几十毫秒，让业务先稳住，再考虑更重的手段，这是我多年实践下来最有价值的一条经验。