TempDB溢出主因是GROUP BY触发哈希或排序内存估算失败后自然落盘，关键看执行计划中Hash Match (Aggregate)或Sort是否带“Warning: Operator used tempdb”；SQL Server用SET STATISTICS XML ON查SpillLevel="1"，MySQL看EXPLAIN中Using temporary，PostgreSQL查EXPLAIN (ANALYZE, BUFFERS)的Actual Total Memory是否超限。
TempDB溢出不是配置没调够，而是GROUP BY触发的哈希或排序操作内存估算失败后自然落盘——关键看执行计划里有没有Hash Match (Aggregate)或Sort带“Warning: Operator used tempdb”警告。
怎么确认是GROUP BY导致的TempDB spill
别猜，直接查执行计划里的物化信号：
- SQL Server：开
SET STATISTICS XML ON，找RelOp PhysicalOp="Hash Match"或PhysicalOp="Sort"节点，看是否有SpillLevel="1"或文字警告Operator used tempdb to spill data - MySQL：用
EXPLAIN FORMAT=TRADITIONAL，重点盯Extra列是否出现Using temporary；若只在子查询行出现，说明物化发生在内层 - PostgreSQL：跑
EXPLAIN (ANALYZE, BUFFERS)，看HashAgg或Sort节点的Actual Total Memory是否远超Granted Memory - 监控辅助：SQL Server查
sys.dm_db_session_space_usage中internal_objects_alloc_page_count是否飙升；MySQL看SHOW STATUS LIKE 'Created_tmp_disk_tables'是否持续上涨
为什么加work_mem或tmp_table_size经常无效
参数只是兜底手段，掩盖不了查询结构问题：
- MySQL中
tmp_table_size和max_heap_table_size取较小值生效——设了512MB但另一项是64MB，实际仍按64MB跑；必须在my.cnf里显式写两行并重启 - PostgreSQL的
work_mem是每个操作独占上限，一个查询含两个GROUP BY就会申请两份；设太高（如256MB）+ 20并发 = 5GB，极易触发系统OOM - SQL Server不靠
min server memory控制单查询内存，而是由优化器基于统计信息预估授予（grant）；grant不足时，哪怕总内存充足，照样spill -
sort_buffer_size（MySQL）或sort_mem（PG）只管ORDER BY，对GROUP BY完全无效
真正有效的优化动作有哪些
绕过中间结果膨胀，让数据库“轻松”完成分组：
- 给
GROUP BY字段建联合索引，且把WHERE条件字段放最左：比如SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY created_date，应建INDEX(status, created_date) - 删掉视图或子查询里的
ORDER BY（除非配TOP）——它不会被外层继承，纯属白占内存和spill空间 - 避免
SELECT *，尤其避开TEXT/BLOB列参与分组；大文本字段改用SHA2(big_text, 256)哈希后分组 - 临时表必须显式建索引：
CREATE TABLE #tmp (user_id INT); CREATE CLUSTERED INDEX IX_#tmp_user_id ON #tmp (user_id);，否则后续所有JOIN都强制扫描+spill - 嵌套CTE或子查询易导致基数误估：子查询返回10行，外层JOIN后实际200万行，优化器仍按10行分配内存；加
OPTION (RECOMPILE)（SQL Server）或/*+ RECOMPILE */（Oracle）可强制重估
容易被忽略的隐性放大器
很多问题表面是GROUP BY，根子在别的地方：
- 快照隔离下长事务未提交：启用
READ_COMMITTED_SNAPSHOT时，只要同一张大表有长事务在更新，GROUP BY查询读取的版本链就一直堆在TempDB里，sys.dm_tran_active_snapshot_database_transactions里elapsed_time_seconds > 300的会话就是元凶 - 客户端拉全量结果：JDBC默认把整个结果集加载进内存，
COUNT(DISTINCT)类聚合一读就崩；MySQL连接串必须加?useCursorFetch=true&defaultFetchSize=500 - 函数表达式破坏索引：视图里写
GROUP BY UPPER(name)或JSON_EXTRACT(data, '$.id')，既无法走索引，又让分组键体积翻倍 - 主键分片比调参更可控：对超大表，先
INSERT INTO #id_range SELECT id FROM big_table WHERE id BETWEEN ? AND ?，再JOIN聚合，每次控几万行，比硬扛千万级GROUP BY稳定得多
