MySQL temptable_max_ram 观察临时表内存阈值如何设置

排查 MySQL 临时表占用内存时，最容易犯的错是只改 temptable_max_ram，然后期待所有查询都能继续留在内存里。这个变量控制的是 TempTable 引擎的全局 RAM 额度；单个内部临时表还受 tmp_table_size 约束，超过全局额度后还要看 temptable_max_mmap 是否允许使用内存映射文件。更稳妥的做法是先读出三者，再按并发查询的总量调整，最后用状态变量和 Performance Schema 复查。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先分清三个阈值，才知道该改哪一个

TempTable 用于 MySQL 处理排序、聚合、派生表、CTE 等产生的内部临时表。temptable_max_ram 控制这个引擎在整个服务器上可以占用的 RAM；达到后，MySQL 8.4 默认转向 InnoDB 磁盘临时表。若配置了非零的 temptable_max_mmap，则会先把后续空间放到内存映射临时文件。

tmp_table_size 是单个内部临时表的最大内存尺寸。它比 temptable_max_ram 小时，即使全局额度很富余，单条查询也会先触发转换。max_heap_table_size 主要在内部临时表使用 MEMORY 引擎时参与限制，不能拿它替代 TempTable 的判断。

先读当前配置，再决定 temptable_max_ram 数值

不要直接套用“机器有多少内存就给临时表多少”的经验值。先确认版本和当前引擎，再把字节数换算成 GiB，与连接数、排序聚合并发和其他内存组件一起估算。

-- 读取版本、内存临时表引擎和三个相关阈值，所有 *_size 都以字节表示
SELECT VERSION() AS mysql_version,
       @@global.internal_tmp_mem_storage_engine AS tmp_engine,
       @@global.temptable_max_ram AS temptable_max_ram_bytes,
       @@global.tmp_table_size AS tmp_table_size_bytes,
       @@global.temptable_max_mmap AS temptable_max_mmap_bytes;

-- 将字节转换为 GiB，便于与主机可用内存和并发量一起评估
SELECT ROUND(@@global.temptable_max_ram / 1024 / 1024 / 1024, 2) AS temptable_max_ram_gib,
       ROUND(@@global.tmp_table_size / 1024 / 1024 / 1024, 2) AS tmp_table_size_gib;

MySQL 8.4 的默认 temptable_max_ram 是服务器总内存的 3%，但默认范围为 1～4 GiB；8.0 到 8.4 升级时不能假定默认值仍然相同。这里先看实际值，再决定是否调整。

用可回滚的全局修改控制整体压力

确认确实需要扩大 TempTable RAM 后，可以先做动态的全局修改。下面只是演示 2 GiB 的写法，不代表任何机器都应该使用这个值；生产环境应先确认 mysqld 的剩余内存和峰值并发。

-- 先保存原值，便于出现内存压力时快速回退
SELECT @@global.temptable_max_ram AS old_value_bytes;

-- 将全局 TempTable RAM 上限设为 2 GiB；新值只作用于全局资源控制
SET GLOBAL temptable_max_ram = 2147483648;

-- 立即读回，确认动态修改已经被服务器接受
SELECT @@global.temptable_max_ram AS current_value_bytes;

提高全局额度只能减少因 TempTable 总额度不足而产生的落盘，不能修复低效的排序、无法使用索引的分组或结果集过大的 SQL。若 tmp_table_size 仍更小，单个查询依旧会在自己的阈值处转换；若把两个值都调大，则要把并发乘数算进去。

调整后观察什么，才能证明阈值设置有效

先看一段时间内的状态变量变化，再看 Performance Schema 的内存分配。Created_tmp_tables 与 Created_tmp_disk_tables 适合做趋势对比，但磁盘计数不会覆盖所有内存映射文件场景，因此不能只依赖一个比例。

-- 记录当前计数作为观察起点；间隔一段业务高峰后再执行一次比较增量
SHOW GLOBAL STATUS LIKE 'Created_tmp%';

-- 查看 TempTable 实际分配到 RAM 与磁盘的空间
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME IN ('memory/temptable/physical_ram',
                     'memory/temptable/physical_disk');

如果 physical_ram 长期接近上限，同时 physical_disk 或磁盘临时表增量上升，说明瓶颈可能还在单表阈值、mmap 配置或 SQL 本身。反过来，如果 RAM 使用平稳而磁盘临时表主要来自少数语句，应优先用执行计划和 sys.statements_with_temp_tables 定位语句，不要继续无条件加大全局内存。

常见问题

temptable_max_ram 越大越好吗？

不是。它是全局额度，并不等于某一条 SQL 的独占额度；并发排序和聚合越多，潜在总占用越高，应给其他缓冲区和连接内存留出余量。

改了 temptable_max_ram，磁盘临时表还在增加怎么办？

检查 tmp_table_size 是否更小、temptable_max_mmap 是否为零，再按语句定位执行计划。参数只能改变资源边界，不能替代索引和查询形状优化。

为什么 Created_tmp_disk_tables 看起来没有覆盖所有落盘？

官方文档说明它不统计以内存映射文件作为 TempTable 溢出机制的临时表，因此应结合 Performance Schema 的 physical_disk 一起看。