千万级MySQL数据表查询慢？从索引到SQL调优的完整实操路径

线上订单表爬到一千两百万行的时候，我第一次被业务方当面催出了冷汗。页面端只是简单加了个筛选条件，用户ID加状态，然后按创建时间倒序分页，SQL跑到了三秒多。主键查询明明还飞快，但一到业务查询就卡到不可用。这种“单表数据量大之后查询变慢”的问题，在MySQL里几乎每个团队都会遇到，网上讲优化的文章也多，但大部分停留在“你要加索引”这种正确却没有用的废话上。

我在这里分享的，是我在真实业务场景中反复测试、踩坑后沉淀下来的一套优化路径，完整覆盖了索引设计、SQL改写、数据模型调整和MySQL参数调优这些层面。无论你是后端开发，还是专职DBA，或者正在准备面试想搞懂千万级MySQL优化到底在调什么，这篇文章都能给你一条可以落地的实操路线。

不要一上来就想着分库分表，那是最后的手段，不是第一选择。绝大多数千万级表性能问题，在索引和SQL层面就能解决大半。

1. 先搞清楚：千万级数据表为什么会变慢

1.1 慢的真正根源：磁盘IO与扫描行数

很多人一提到“MySQL慢”，本能认为是“数据太多了，数据库扛不住了”，接着就想上分布式中间件、分库分表。但你先别急，先想想InnoDB的存储结构。MySQL的InnoDB引擎用B+树来组织索引，聚簇索引的叶子节点直接存整行数据。理论上，一张表即使有几千万行，只要走的是合适的索引，B+树的层级通常也就三到四层。每次查询只是沿着树做几次磁盘IO就能拿到目标数据，主键查询毫秒级是完全正常的。

既然结构上不存在问题，那慢在哪里？慢在“扫描了太多用不上的行”。我们做性能分析时，最核心的指标不是“表有多大”，而是“这条SQL扫描了多少行，返回了多少行”。两者差距越大，浪费越明显。比如一条分页SQL要取最后一页20条数据，MySQL得先把前面几十万行全读出来，再丢弃掉，这个成本自然高得吓人。此外还有几个容易被忽略的隐藏因素：

• 回表次数过多。普通二级索引只存索引字段和主键，查询需要其他列时必须回到聚簇索引再读一次完整数据。
• 排序无法利用索引，产生临时文件和filesort。
• 索引虽然建了，因为SQL写法问题压根没走上。
• 锁等待。不只是慢查询本身，还可能是在等别的事务释放行锁。

先理解“慢的本质是IO和扫描行，而不是单纯的行数”，后面所有优化动作才有方向。

1.2 优化前，先给数据库做一次“体检”

我见过不少同学上来就凭感觉建索引，今天加一个明天删一个，本来几十毫秒的查询被越调越慢。做优化前，必须用数据说话。这里给你一套我常用的“体检清单”，第一步就是打开慢查询日志。

sql复制-- 查看当前慢查询日志状态
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

-- 开启慢查询日志并设置阈值（生产环境建议设为1秒）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

等运行一段时间后，日志里自然会把超过阈值的SQL全记录下来，这就是第一批待优化目标。记得慢日志文件要用专门的磁盘目录存放，别和数据目录挤在一起，否则高并发下日志本身也会形成IO瓶颈。

第二步，查看各个表的行数和数据大小，锁定哪些表才是真正的大表。

sql复制SELECT 
  table_schema,
  table_name,
  table_rows,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = 'your_db'
ORDER BY total_mb DESC LIMIT 20;

注意table_rows在InnoDB里是估算值，不准，但它能帮你快速筛出目标。

第三步，分析磁盘IO能力。有时候不是SQL写得差，而是机器本身磁盘IOPS不够。建议用fio或者dd工具做个基准测试。如果随机读IOPS很低，那你代码调得再漂亮也是杯水车薪，那是硬件层面先要解决的问题。

完成这三步体检，你手里就有了一份问题清单，接下来再针对具体SQL去优化，而不是大海捞针。

2. 索引优化：千万级表的第一道救命绳

2.1 联合索引字段顺序：细节决定生死

所有索引优化里，最值得花时间研究的就是联合索引。我们线上有一个订单表，结构大致是这样（已简化）：

业务方有一个高频查询：按用户查订单，再按状态过滤，按创建时间倒序分页返回。最开始我建的是单个字段索引 idx_user_id(user_id)，执行计划也没问题，但查询效率一般。后面我改成了联合索引：

sql复制ALTER TABLE `order` ADD INDEX idx_user_status_created (user_id, status, created_at);

为什么这样建？核心是两条原则。第一，区分度高的字段放前面。user_id区分度比status高得多，把user_id放在最左边，索引才能快速收敛范围。第二，把排序字段加入到索引中，且保持和排序方向一致。查询条件里是 created_at DESC，建索引时默认是ASC，MySQL在8.0之后支持降序索引，但大多数场景下反向扫描也能利用ASC索引完成排序，所以问题不大。

这里最重要的一点是覆盖查询中排序字段。如果在created_at上不建立索引，即使前面where条件很精准，MySQL还是得把查出来的数据再按created_at做一次filesort，一旦结果集大，性能立刻恶化。而把created_at放进联合索引，查询就能顺着索引顺序直接完成排序和过滤，Extra里再也不会出现Using filesort。

2.2 覆盖索引与索引下推：让SQL少回两次表

联合索引至少还能带来两个隐藏收益：覆盖索引（Covering Index）和索引下推（Index Condition Pushdown，ICP）。

覆盖索引指的是查询要的列全部包含在索引中，这样MySQL就不需要回表读完整行记录。比如首页列表只需要显示订单号、状态、金额和创建时间，你可以把SQL写成：

sql复制SELECT id, order_no, status, created_at 
FROM `order`
WHERE user_id = 12345 AND status = 2
ORDER BY created_at DESC
LIMIT 20;

假如只建了 idx_user_status_created(user_id, status, created_at) 这个索引，那么除了id和order_no中包含order_no不在索引里，id是附加的聚簇主键又额外回表。要真正做到不回表，索引列还得包含order_no、amount等要查询的列。这里就有了“冗余索引”和“覆盖查询”的权衡。

另外MySQL 5.6以后引入了ICP，查询条件中部分无法使用索引的过滤条件会被下推到存储引擎层判断，提前过滤掉不需要回表的行。你在执行计划Extra里看到Using index condition，就说明ICP生效了。这个机制对减少回表次数有显著帮助。

再说句实在话：在有索引的情况下，别再用 SELECT *。每多一个不在索引里的字段，就可能增加一次回表。宽表碰到高频查询，建议用覆盖索引把常用字段包进去，前提是别让索引列数膨胀得太夸张，否则写入放大也很痛苦。

2.3 用EXPLAIN读懂SQL的真实“体检报告”

索引建得好不好，最终要看执行计划。很多面试题里讲explain，讲来讲去都是背字段含义，真到了调优场景却不知道怎么用。我给你提炼一个最精简的排查路径。

执行计划里重点看四列：type、key、rows、Extra。

常用的排查动作是这样：先看type是不是ref或range，如果是ALL，去看where条件字段是不是没有索引，或者有索引却因为写法问题失效。然后看rows是否在合理范围，再用Extra确认是否存在排序和分组产生的临时表。

举个实际例子，一条SQL明明where条件里有索引列，执行计划却显示ALL。检查后发现SQL里对索引字段做了函数操作：

sql复制SELECT * FROM user WHERE DATE(created_at) = '2024-01-01';

created_at上虽然有索引，但套上DATE()函数后，索引就失效了。正确写法是范围查询：

sql复制SELECT * FROM user 
WHERE created_at >= '2024-01-01' 
  AND created_at < '2024-01-02';

这种通过函数包裹索引列导致索引失效的坑，属于经典中的经典。调优的时候一定要把SQL拿到explain里走一遍再下结论。

3. SQL改写：不换架构也能救回不少性能

3.1 深分页问题的破解与延迟关联

千万级数据表最常见的一个性能杀手，就是深分页。业务系统里几乎都有这种需求：用户翻到第1000页、第10000页。如果你用最普通的写法：

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

这条SQL的逻辑是先把满足条件的1000020行全部读出来，然后丢弃前100万行，只返回最后20行。我之前统计过，一条这样的SQL到了百万级偏移量，耗时能到四五秒。这不是索引没有，而是MySQL必须扫描那么多行才能找到起点，回表和排序损耗都很大。

解决深分页通常有两个思路。

第一种是延迟关联。先使用覆盖索引定位到目标行的主键ID，再用这些ID回表取完整数据：

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

子查询里的临时表只查id，全部从索引里拿，不需要回表。虽然它仍然要扫描100万行索引，但每行只有id和索引字段，体积小，速度快得多，然后再通过主键关联回去取20行完整数据即可。

第二种是书签法，更适合那种只需要“下一页”操作的场景。记住上一页最后一个id，往下翻时直接用id作为起点：

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

这个写法利用了主键的有序性，完全回避了LIMIT偏移量带来的扫描浪费。它其实改变了排序语义，从按创建时间排序变成了按主键id排序，如果业务上能接受按主键排序（在订单等递增场景中通常没问题），性能会再上一个台阶。

3.2 隐式类型转换与常见索引失效写法

很多查询刚开始很快，随着业务复杂化越写越乱，SQL里各种隐式类型转换、前模糊查询、OR拼接，愣是把好端端的索引作废了。我把这些年线上排查到的高频问题整理成一个速查：

这里我重点说一下隐式类型转换。我们有个表用varchar存手机号（实际上手机号更适合用varchar，因为可能涉及前缀匹配），线上代码误把手机号当作数字类型传过来，MySQL在比较时会把varchar列转成数字，一旦对索引列做转换，B+树就无法快速定位，只能全索引扫描。这类问题用explain一眼就能看出来，rows会非常大。

另外要注意，优化器有时候会被OR带偏。当SQL里同时存在等式条件和OR条件，MySQL可能选择全表扫描，哪怕其中某些字段有索引。这种情况可以把OR条件改写为UNION ALL两条索引查询，效果往往立竿见影。做这些改写的前提是，你清楚业务数据的特性，不会因为改写引入重复数据或逻辑差错。

4. 数据模型与架构层调整：什么时候该动表结构

4.1 拆分表结构的边界判断：别再盲目分库分表

当索引和SQL层面已经优化到位，单表查询仍然扛不住业务流量时，才需要认真考虑拆分。但拆分不是“表数据到千万就必须拆”，它要结合两个指标一起看：数据量级和写入并发。

如果量级到了五千多万甚至上亿行，同时写入QPS也比较高，索引维护成本开始明显上升，插入一条记录需要更新的索引页变多，磁盘IO压力变大。这时的选择通常有三类：冷热归档、垂直拆分、水平拆分。

垂直拆分相对简单，把一张宽表按照访问频率拆成多张窄表。比如把订单基本信息、订单扩展信息、订单物流信息拆开。高频查询只访问核心表，低变更新和低频查询放扩展表。举一个场景：订单表里有几个字段是给财务对账用的，平时用户端查询根本用不到，但字段又大又占内存。拆走这些字段后，核心表的行宽变短，一个数据页能放更多行，扫描效率自然提升。

水平拆分则要复杂很多，必须设计好分片键。订单表最常用的分片键是user_id，或者order_id。我见过最稳妥的方案是优先按user_id分片，因为用户端查询都会带user_id，这样能保证一次请求只落到一个分片。千万不要选一个查询里不带的分片键，否则每次查询都要广播到所有分片做聚合，这种拆分的代价比不拆还大。

4.2 冷热数据归档：最被低估的降本增效方案

这里面我要强烈推荐一种方案，它比分库分表简单得多，效果却极其显著，就是冷热数据归档。

我们有张流水表，每天新增几百万行，但业务上真正高频访问的基本都是近三个月的热数据。早年的数据不仅很少被查询，还占着索引空间，拖慢整体性能。与其费劲做数据库中间件，不如把超过一定时间的数据迁移到一张历史归档表，或者干脆迁移到另一台机器上的冷库实例。

实际操作时，推荐用pt-archiver或者DataX这类工具做批量归档。比如用pt-archiver分批删除并插入数据：

bash复制pt-archiver \
  --source h=localhost,D=your_db,t=order \
  --dest h=localhost,D=your_db,t=order_history \
  --where "created_at < DATE_SUB(NOW(), INTERVAL 6 MONTH)" \
  --limit 2000 \
  --commit-each \
  --purge

用--limit 2000和--commit-each能控制每次处理2000行，避免一次性大事务锁住大量行导致主库高峰期阻塞。它一边从源表查老数据写入归档表，一边从源表删除，工具内部会自动控制节奏，比写存储过程硬删要优雅得多。

我也看到不少团队用DataX做全量历史数据同步，它可配置的参数很多，适合一次性把百万级旧数据从在线实例搬到离线分析库，但日常周期性的归档任务用pt-archiver更轻量。

归档完成之后，在线表的行数降到可控范围，索引热区重新集中到最近数据，查询和写入都会有肉眼可见的提升。而且冷数据如果还有偶尔查询需求，可以在归档表上单独建索引，和应用层做个路由，先查热表查不到再走冷表，体验上几乎无缝。

4.3 读写分离与主从延迟的矛盾点

解决读多写少的场景，另一个常用手段是主从读写分离。MySQL主库负责写入，从库负责读流量，应用层配置多数据源或者走中间件。但读写分离不是零成本，核心矛盾在于主从之间的复制延迟。

业务上如果用户刚下单成功，立刻刷新订单列表，而读请求先落到了从库，从库还没同步完这条最新订单，用户会看到数据“丢失”，这种体验很难接受。我在生产环境里见过最离谱的延迟，是大事务把主库binlog推送堵住了，从库延迟到十分钟以上。

所以我不推荐所有读流量都无脑走从库。稳定的做法是：核心实时性要求高的读请求强制走主库，比如支付结果页、订单详情页。可以接受稍许延迟的列表页、统计页走从库。实现方式可以在DAO层做数据源路由，或者用一个简单的标识参数区分forceMaster和默认slave。

另外主从架构下有个参数特别值得关注，就是主库的binlog_format和sync_binlog。高并发写入场景，binlog最好设置为ROW模式，能精确记录每一行变更，虽然日志量会比STATEMENT模式大一些，但从库重放更安全。同时sync_binlog控制binlog刷盘频率，生产环境建议设为1，保证主库崩掉也能最大程度不丢数据，代价是写入性能下降，需要靠硬件和批量提交优化来弥补。

5. MySQL配置与运维调优：让引擎吃得更饱、干得更快

5.1 缓冲池与关键参数：先从内存利用抓起

有时候SQL写得没错，索引也在，但还是慢，问题可能出在MySQL整体配置没有跟上机器硬件。特别是InnoDB的缓冲池，直接决定数据页的缓存命中率。如果缓冲池太小，热点数据频繁被换出，每次查询都要走磁盘，性能自然上不去。

最常用的参数调整，我先列出来：

我记得第一次给一台64G内存的数据库服务器调整配置时，把innodb_buffer_pool_size从默认的128M调到了40G，原来一批慢查询直接从2秒降到100毫秒内，效果就是这么立竿见影。很多人装完MySQL不调配置，用着默认小缓冲池跑大表，这相当于把跑车开在泥路上。

需要特别提醒的是，innodb_flush_log_at_trx_commit=1虽然安全，每次事务提交都要强制刷盘，在机械硬盘上性能损失明显。如果业务可以容忍最多丢失一两秒的事务日志，可以设置为2，让MySQL每秒批量刷一次。设置成2之后写入性能会有一个明显提升，但前提是你能接受极端宕机情况下的数据丢失风险，不能一刀切照搬。

5.2 大事务与锁表：千万级表上的隐形杀手

当表数据量达到千万级，一个大事务可能引起的锁范围会比预想中大很多。InnoDB默认隔离级别是Repeatable Read，在这个级别下，不仅会对命中的行加锁，还会对索引范围加间隙锁（Gap Lock），防止其他事务插入间隙数据。如果你的业务SQL查询条件很宽泛，无意中就会把一个范围内的所有间隙锁住，导致其他事务被长时间阻塞。

我排查过一个线上问题：业务方凌晨跑批，把一个几百万行的状态批量UPDATE成新值，然后这个事务执行了两分钟没提交。期间所有新增订单都卡在插入阶段，用户端直接报超时。根本原因是批量更新覆盖的范围过大，InnoDB要锁住的行和间隙过多，加上binlog同步延后，整个数据库的并发写入都被堵住了。

这里给的实操建议是：大批量操作必须拆分。比如一次更新50万行，拆成每5000行一个事务，循环执行，每次提交后sleep一下。5000行这个量级是经验值，可以根据线上IO情况微调。宁可多花一点总时间，也要避免单次事务长时间持锁。

另外，如果业务对事务隔离级别要求没那么高，可以评估把线上库从Repeatable Read改成Read Committed。RC级别下InnoDB只会锁住命中的行，不会加间隙锁，并发死锁和锁等待的概率会明显下降。阿里的很多生产规范也推荐使用RC，但要评估业务里有没有依赖不可重复读或间隙锁特性，不能贸然切换。

5.3 通过监控指标持续验证优化效果

没有监控的优化就是在裸奔。我建议至少把下面几个指标接到你的监控系统里：

• QPS、TPS，判断整体吞吐变化。
• 慢查询数量和最长耗时，看有没有新增的慢SQL。
• InnoDB Buffer Pool命中率，正常情况下应该长期在99%以上。
• Threads_running、Threads_connected，判断连接池和线程资源是否够用。
• 主从复制延迟时间，防止读写分离链路拖垮业务。
• 锁等待次数，用SHOW ENGINE INNODB STATUS查看锁信息。

优化完一批SQL后，我习惯把这些指标跑两周，观察趋势是否平稳。如果慢查询数量重新抬头，就要回头分析是不是数据量又涨到了新的量级，还是新业务代码带入了新的低效SQL。数据库优化不是一次性的动作，而是一个跟随业务持续迭代的过程。

6. 常见问题与实战排查技巧

6.1 千万级表优化常见问题速查

把这段时间实际处理过的问题整理成一张速查表，大家遇到同类问题可以直接对照：

6.2 我踩过的一些实操坑

最后分享几个真实的踩坑经历。

第一，是直接在生产库上执行DDL导致的锁表。当初为了加一个普通索引，我直接跑了一条ALTER TABLE，在千万级表上花了很长时间，期间InnoDB虽然支持在线DDL，但索引创建仍然会带来额外开销和元数据锁等待，结果业务侧出现瞬间的卡顿。后面我改用了percona工具pt-online-schema-change，在夜间低峰期执行，先创建新表，再通过触发器同步增量数据，完成后再切换，对在线业务的影响降到了最低。

第二，是过度相信单列索引。早期给表加了一堆单列索引，以为每个查询条件都能命中，结果优化器经常选错索引，甚至因为回表次数太多比全表扫描还慢。后来才明白，单列索引之间很难联合生效，大多数场景都应该设计联合索引，考虑字段顺序和SQL匹配规则。

第三，是忽略字符集排序规则。两个表联查时，一张表是utf8mb4_general_ci，另一张是utf8mb4_unicode_ci，如果字符集不同但字段内容和长度一样，虽然能正常关联，但索引使用上会受到隐含转换影响。检查时需要注意对比字段的排序规则是否一致，不一致时尽早统一。

根据我个人的经验，MySQL千万级表优化最忌讳的就是看到一个慢SQL就急着动表结构，也不建议盲目套用分库分表框架。先把问题量化清楚，从索引和SQL改写入手，再考虑冷热分层和读写分离，如果依然扛不住，最后才上分片。这个顺序走下来，绝大多数业务场景都能在成本可控的情况下拿到明显的性能提升。