SELECT INTO #temp易致内存溢出，因其无预定义结构、不建索引、隐式全表扫描且优化器低估内存需求；应改用显式建表+建索引+UPDATE STATISTICS，并分批插入、及时清理、合理配置tempdb。
临时表内存溢出不是“数据太大”，而是 SQL Server 或 MySQL 在插入过程中没控制好内存申请节奏——尤其用 SELECT INTO #temp、没建索引、或在循环里反复追加数据时，tempdb 或 innodb_buffer_pool 会迅速被撑爆。
为什么 SELECT INTO #temp 容易触发 OOM？
它不预定义结构，无法提前建索引，且隐式触发全表扫描+完整日志记录；SQL Server 优化器无法准确预估行数，常低估内存需求，导致运行时分配不足。MySQL 的 CREATE TEMPORARY TABLE SELECT 同理，跳过索引阶段，统计信息为空，JOIN 或 GROUP BY 时极易落盘。
- 改用显式建表：
CREATE TABLE #temp (id INT, content LONGTEXT); CREATE INDEX IX_temp_id ON #temp (id); - 再执行
INSERT INTO #temp SELECT ...，让引擎基于已有索引和统计信息做更准的内存授予 - SQL Server 2019+ 中，
SELECT INTO仍不自动创建统计信息，必须手动UPDATE STATISTICS #temp;
临时表没索引，JOIN 就卡死
几十万行数据往 #temp_table 一塞，后续 JOIN 或 WHERE status_id = ? 就开始全表扫描——tempdb 内存页疯狂分配，最后报 Could not allocate space for object 'dbo.#temp_table' in database 'tempdb'，这不是磁盘满，是内存页分配失败。
- INSERT 完立刻建索引：
CREATE NONCLUSTERED INDEX IX_temp_status_created ON #temp_table (status_id, created_time); - 避免在存储过程循环中反复
INSERT INTO #temp_table而不清理；小数据量改用表变量@table_var，大数据量则分批 + 显式DROP TABLE #temp_table - 检查
tempdb文件是否均分在多个物理磁盘上；单个数据文件是常见瓶颈
分批插入时容易忽略的三个细节
用 @BatchSize = 5000 分片看似稳妥，但若没处理好边界、排序字段缺失或日志截断机制，照样会因累积事务日志或锁等待引发超时或内存抖动。
- 别依赖
@@ROWCOUNT == @BatchSize判断是否继续循环——最后一批常不足，应以@MinID < @MaxID为准 - 确保有可排序、可分段的字段（如
id）；没有的话，用SELECT TOP (@BatchSize) ... ORDER BY (SELECT NULL) OUTPUT INTO #batch做无序分片，但需额外去重逻辑 - 在简单恢复模式下，每批后加
CHECKPOINT可及时截断日志；完整恢复模式下无效，得靠定期日志备份释放空间
最常被跳过的动作：分批前先确认目标表是否有合适索引支撑 WHERE id BETWEEN x AND y ——否则每次都是全表扫描，分批就失去意义。临时表本身也要索引，而不仅仅是主表。
