直接大批量JOIN INSERT会卡死或超时，因优化器可能选错执行计划，导致全表扫描、嵌套循环或临时表撑爆内存；应分批处理，每次5k–50k行，用带索引的临时表精准驱动JOIN，并通过EXPLAIN验证执行计划是否走索引。
为什么直接大批量 JOIN INSERT 会卡死或超时
因为数据库执行 INSERT ... SELECT ... JOIN 时，如果关联表或目标表数据量上百万，优化器可能选错执行计划——比如对大表做全表扫描再嵌套循环，或者临时生成巨大中间结果集撑爆内存/磁盘临时表空间。常见现象是：语句执行几分钟没反应、SHOW PROCESSLIST 显示 Copying to tmp table 或 Sorting result 持续不退、甚至触发 max_heap_table_size 或 tmp_table_size 限制报错 ERROR 1104 (42000): The SELECT would examine more than MAX_JOIN_SIZE rows。
用临时表分批 JOIN 的核心操作步骤
本质是把“一次性大关联”拆成“多次小范围精准关联”，关键不在“建临时表”，而在“控制每次 JOIN 的数据边界”。推荐用主键/自增 ID 或时间字段分段，避免 LIMIT OFFSET 分页（深度偏移性能差）：
- 先建带索引的临时表：
CREATE TEMPORARY TABLE temp_batch AS SELECT id FROM large_table WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31';，然后ALTER TABLE temp_batch ADD INDEX idx_id (id); - 用这个临时表驱动 JOIN：
INSERT INTO target_table (...) SELECT ... FROM temp_batch t JOIN big_dim_table d ON t.id = d.ref_id WHERE d.status = 1; - 每次处理完一批后清空或重置临时表（
TRUNCATE TEMPORARY TABLE temp_batch），再填充下一批 ID 范围
分批大小怎么定才不慢也不崩
没有固定值，取决于你的 join_buffer_size、可用内存和关联字段索引质量。实测经验：
- 单次处理 5k–50k 行较稳妥；超过 10 万容易触发磁盘临时表
- 如果关联条件上有联合索引（如
(ref_id, status)），可适当放大到 10 万；若只有单列ref_id索引，建议压到 2 万以内 - 务必在分批前加
EXPLAIN验证执行计划：确认type是ref或range，不是ALL；rows预估值应接近你设定的批次大小，而非整个大表行数
临时表用 MEMORY 还是 InnoDB？
别盲目选 MEMORY。它看似快，但有硬伤：
-
MEMORY表不支持TEXT/BLOB，也不支持全文索引；更关键的是，如果临时表数据量超过max_heap_table_size，MySQL 会自动转成磁盘表（InnoDB 或 MyISAM），反而多一次转换开销 - 生产环境更推荐
CREATE TEMPORARY TABLE ... ENGINE=InnoDB，配合足够大的innodb_buffer_pool_size，实际性能差距很小，且行为稳定可控 - 如果只是存 ID 列（INT/BIGINT），且总量确定小于 64MB，
MEMORY可以用，但必须显式设置MAX_ROWS和检查max_heap_table_size当前值
分批逻辑本身不难，真正容易被绕进去的是：以为建了临时表就万事大吉，却没验证每次 JOIN 是否真的走索引、没监控临时表实际落盘情况、也没根据执行计划动态调批次大小。
