mysql大数据量导出时join卡死，应禁用limit offset分页，改用straight_join强制驱动表顺序、确保join字段有匹配索引、精简select字段，并优先采用流式查询或分片关联替代单次大join。
MySQL 大数据量导出时 JOIN 导致卡死怎么办
直接在导出 SQL 中写 JOIN 多张大表，尤其是带 LIMIT OFFSET 分页的，90% 以上会触发全表扫描 + 临时表 + 文件排序，查几万行就超时或 OOM。根本原因不是数据多，而是 MySQL 在执行计划里没走索引驱动表，反而把小表当驱动表去循环匹配大表。
常见错误现象：EXPLAIN 显示 type=ALL、Extra=Using temporary; Using filesort；导出接口响应时间从几百毫秒跳到几十秒；数据库连接池被长期占用。
- 确认驱动表：用
STRAIGHT_JOIN强制指定左表为驱动表，避免优化器误判 - JOIN 条件字段必须有索引，且类型严格一致（比如
INT和BIGINT关联会失效） - 避免
SELECT *，只查导出需要的字段，减少网络和内存开销 - 如果关联表数据量远大于主表（比如订单表 JOIN 用户表，但用户表千万级），优先考虑在应用层用主键 ID 批量 IN 查询，而不是 SQL JOIN
流式查询（Streaming Result）为什么比分页更稳
流式查询本质是让 JDBC 不缓存结果集，边取边处理，内存占用恒定在 KB 级别；而分页方案即使每页 1000 行，也要反复建 Paginator、反复查 COUNT、反复拼 OFFSET，offset 超过 10 万后性能断崖下跌。
关键限制：必须关闭 MySQL 的 useCursorFetch 默认行为，显式启用流式；且不能用 ResultSet.next() 以外的方式遍历（比如转成 List 就失效）。
- MySQL 连接参数加
&useServerPrepStmts=false&cachePrepStmts=false&defaultFetchSize=0 - Java 侧用
Statement.setFetchSize(Integer.MIN_VALUE)启用流式游标 - 必须在同一个
Connection和Statement生命周期内完成读取，中途不能 commit 或 close - 不支持
ORDER BY后再流式（除非排序字段有覆盖索引且能走索引扫描）
分片关联（Sharded JOIN）怎么落地
当必须 JOIN 且两边都超大时，靠单条 SQL 优化已无意义。分片关联是把“一次大 JOIN”拆成“N 次小 JOIN”，核心是利用主键/时间范围做数据切片，让每次查询都能命中索引。
典型场景：导出 2024 年全部订单 + 商品信息，订单表 800 万，商品表 500 万。直接 JOIN 几乎必崩；但按订单 ID 分段（如每 5 万 ID 一段），再用 IN (id1,id2,...) 关联商品，就能稳定压测 1000 QPS。
- 切片依据优先选主键或带索引的时间字段，避免用业务字段（如 user_id）导致数据倾斜
- 分片大小建议 1–5 万，太小增加网络往返，太大仍可能触发临时表
- 商品表等维表必须建好
PRIMARY KEY或UNIQUE INDEX，否则IN查还是会慢 - 应用层需控制并发数（比如用
Semaphore限 4–8 路并行），防止 DB 端连接打满
流式 + 分片混合方案最容易被忽略的坑
有人想“既流式又分片”，比如一边流式读订单，一边按批次异步查商品——这会导致商品数据乱序、内存泄漏、甚至事务隔离问题。流式本身是单连接单游标模型，和分片的多连接多查询模型天然冲突。
真正可行的混合，是“流式读主表 → 写入临时文件 → 分片查维表 → 合并生成最终 Excel”。中间必须落盘，不能全在内存拼。
- 临时文件建议用
/tmp/export_XXXXX.csv，避免堆内存溢出 - 维表查询务必加
FOR UPDATE SKIP LOCKED（如果涉及更新）或至少READ COMMITTED隔离级别 - 分片任务失败要可重试，且记录已处理的主键范围，避免重复导出
- 最后合并阶段不要用 Apache POI 直接追加单元格，改用
SXSSFWorkbook或EasyExcel的 writeSheet 模式
