真正起作用的是 tmp_table_size 和 max_heap_table_size 中的较小值；两者需设为相同值，且 max_heap_table_size 还影响 MEMORY 表；ORDER BY/GROUP BY 未走索引会触发临时表，应优先加复合索引。
tmp_table_size 和 max_heap_table_size 到底谁说了算？
MySQL 临时表爆内存或频繁落盘，** 不是调大 tmp_table_size 就完事了 **——真正起作用的是它和 max_heap_table_size 中的较小值。哪怕你把 tmp_table_size 设成 2G，只要 max_heap_table_size 还是默认的 16M，那所有内存临时表一过 16M 就立刻转磁盘。
- 两个参数都得改，且建议设为相同值，避免隐性瓶颈
- 修改后必须重启 MySQL（5.7 及以前）或至少重连会话（8.0+ 动态生效部分场景，但临时表行为仍受全局值约束）
-
max_heap_table_size还管着你显式创建的CREATE TABLE …… ENGINE=MEMORY表，别只盯着临时表忽略其他用途
ORDER BY / GROUP BY 大量落盘？先看执行计划再调参
调大内存阈值只是“止痛”，真正让临时表不暴涨，得让 MySQL 少用临时表。最常见诱因是 ORDER BY 或 GROUP BY 没走索引，被迫在内存里建大表排序。
- 用
EXPLAIN FORMAT=TREE（8.0）或EXPLAIN看Extra字段：出现Using temporary就是触发了临时表 - 优先加复合索引覆盖排序字段 +WHERE 条件，比如
WHERE status=1 ORDER BY created_at DESC，建索引(status, created_at) - 避免在
ORDER BY里用函数或表达式，如ORDER BY DATE(created_at)，这会让索引失效
UNION 和多表 JOIN 导致 ibtmp1 疯长？拆查询比扩空间更治本
MySQL 8.0+ 的磁盘临时表默认走 InnoDB，写入 ibtmp1 文件——这个文件只增不缩，一次大查询就可能让它涨到几十 GB，且无法在线 shrink。
- 别急着删
ibtmp1：必须先设innodb_fast_shutdown=0，再停库、删文件、重启，否则下次启动可能崩溃 - 更稳妥的做法是拆 SQL：先把主键 ID 拿出来排序分页，再用
IN查详情，像这样：SELECT id FROM t WHERE …… ORDER BY modify_time DESC LIMIT 20→ 再SELECT * FROM t WHERE id IN (……) - 如果必须 JOIN 多张大表，确认每张表的关联字段都有索引，尤其注意
LEFT JOIN右表的ON条件字段是否被索引覆盖
Oracle 临时表空间爆满时，别只盯着 TEMP 文件大小
ORA-01652 报错表面是空间不够，实际往往卡在“找不到连续 extent”，而根源常是大量未释放的临时段——尤其是长事务、没加索引的排序、或笛卡尔积查询。
- 查谁在占空间：
SELECT username, sid, serial#, sql_id, tablespace, segtype FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr - 杀掉异常会话后，执行
ALTER TABLESPACE TEMP COALESCE合并空闲区，比单纯加数据文件更有效 - 临时表空间组（tablespace group）是更健壮的方案：多个 tempfile 分散 I/O，还能动态切换默认临时表空间，避免单点打满
临时表问题从来不是单一配置能解决的。参数调得再大，遇上没索引的 GROUP BY 或全表扫描的 UNION，照样落盘、暴涨、IO 拉满。最该花时间的地方，其实是看懂 EXPLAIN 输出里的那一行 Using temporary。
