大表关联超时的根本原因是数据库需一次性处理上亿行数据，导致内存耗尽、临时文件暴涨、执行计划退化；此时分片关联不是优化选项而是唯一可行路径，须确保每批都下推过滤、索引可用、内存可控。
大表关联大表超时，不是SQL写得不够“聪明”，而是数据库在尝试一次性加载、匹配几千万甚至上亿行数据时，内存耗尽、临时文件暴涨、执行计划退化为全表扫描——这时分片关联不是“优化选项”，是唯一能跑通的路径。
为什么EXPLAIN里看到Seq Scan或Hash Join Rows=1e8就该停手
PostgreSQL 或 MySQL 的 EXPLAIN ANALYZE 如果显示对某张大表走 Seq Scan，且预估或实际处理行数超过 500 万，基本可以判定这次 JOIN 已经失控。更危险的是：即使显示用了 Hash Join，但 Rows Removed by Filter 占比极高（比如 99%），说明哈希表构建了大量无效数据，内存和 CPU 都在空转。
- 别急着加索引——先确认关联字段类型是否一致：
user_id INT和ref_id VARCHAR强制隐式转换，索引直接失效 -
ON UPPER(a.name) = UPPER(b.name)这类写法会让任何索引失效，必须改用函数索引或标准化存储 - MySQL 的
join_buffer_size默认仅 256KB，撑不住百万级关联；PG 的work_mem默认 4MB，超 10 万行哈希就可能落盘，拖慢十倍
用主键范围分片比时间字段切分更稳
时间字段（如 created_at）看着自然，但极易出问题：存在 NULL、重复值、批量补录导致乱序、业务逻辑中“未来时间”写入……这些都会让分片边界错位，漏数据或重复处理。
- 优先选有索引的单调主键：
id（自增）、uuid_v7、ts_ms（毫秒时间戳整型） - 先查边界：
SELECT MIN(id), MAX(id) FROM orders;，再按固定步长切，例如每批 8 万：WHERE id BETWEEN 1 AND 80000 - 避免
id % 100 = 0这类取模分片——数据倾斜时，某些批次为空，某些批次卡死在单个热点 ID 上 - 子查询中必须保留原始
id字段，否则后续多批次结果合并时无法校验或去重
临时表不建索引 = 白忙一场
把几百万行塞进 CREATE TEMP TABLE AS SELECT 后就直接 JOIN，等于把性能问题从“原表扫描”转移到“临时表扫描”。没索引的临时表，后续所有 WHERE、JOIN、ORDER BY 都只能全表扫。
- MySQL：
CREATE TEMPORARY TABLE tmp_orders AS SELECT ...后立刻执行ALTER TABLE tmp_orders ADD INDEX idx_user_id (user_id); - PostgreSQL：先建结构
CREATE TEMP TABLE tmp_orders (LIKE orders INCLUDING ALL) WITH NO DATA;，再INSERT INTO tmp_orders SELECT ...，最后CREATE INDEX ON tmp_orders(user_id);——避免 INSERT 过程中锁表太久 - 别给临时表加外键、触发器、FULLTEXT 索引，纯作数据中转，越轻量越好
- 如果只是单次关联且数据量 WITH）更省资源；但 CTE 不支持建索引，超量慎用
UNION ALL 合并批次结果前必须校验主键冲突
分批查完用 UNION ALL 拼接看似简单，但隐患极深：边界计算误差（比如 BETWEEN 100001 AND 200000 和 BETWEEN 200001 AND 300000 中间漏掉 200000.5？虽然主键是整型，但并发写入时可能有间隙）、或一对多 JOIN 导致同一条主表记录在不同批次里关联出不同副表行——最终结果集顺序错乱、主键重复、统计口径失真。
- 合并前先抽样检查：
SELECT id, COUNT(*) FROM result_table GROUP BY id HAVING COUNT(*) > 1; - 若业务允许，用
INSERT ... ON CONFLICT DO NOTHING（PG）或INSERT IGNORE（MySQL）入库，靠主键约束自动去重 - 更稳妥的做法：每批结果写入带批次标识的普通表（如
result_20260501_batch_001），后续用视图或应用层聚合，留痕可追溯
真正难的不是写出分片逻辑，而是在每一批里都保持过滤下推、索引可用、内存可控——稍一松懈，某一批就会因没走索引或 work_mem 不足而拖垮整个流程。分片不是拆解问题，是把一个不可控的大问题，变成一组可控的小问题；而每个小问题，仍需按单表高性能查询的标准来对待。
