max_heap_table_size 应与 tmp_table_size 设为相等，且不超过服务器可用内存的20%～30%，常见安全值为64M～128M；两者取较小者生效，动态修改仅影响新连接，需结合状态变量验证效果。
max_heap_table_size 设为多大才不会被临时表撑爆内存
它不是“越大越好”，而是要和 tmp_table_size 协同设置，且必须 ≤ 服务器可用内存的 20%～30%，否则容易触发 OOM 或被 Linux OOM killer 杀掉进程。
-
max_heap_table_size控制单个 MEMORY 引擎表（包括隐式创建的内部临时表）的最大内存上限 -
tmp_table_size控制查询中自动创建的内部临时表（如 GROUP BY、ORDER BY）在内存中能用多大；当超过该值，MySQL 会退化为磁盘临时表（MyISAM或InnoDB） - 两个值取较小者生效 —— 比如你设
max_heap_table_size=256M、tmp_table_size=128M，那实际能用的还是 128M - 线上建议：两者设为相等，避免行为不一致；常见安全值是
64M～128M（8GB 内存机器起步）
为什么改了 max_heap_table_size 还是用磁盘临时表
最常见原因是没同步调大 tmp_table_size，或者查询本身不满足内存表使用条件（比如含 TEXT/BLOB 字段、用了 UNION 中的非全部字段排序等）。
- 检查当前生效值：
SHOW VARIABLES LIKE 'max_heap_table_size';<br>SHOW VARIABLES LIKE 'tmp_table_size';
- 确认某次查询是否用了磁盘临时表：
EXPLAIN FORMAT=JSON查看using_temporary_table是否为true，再结合created_tmp_disk_tables状态变量增长判断 - 注意：即使两个 size 都够，只要查询涉及
MAX()+GROUP BY混合、或排序字段总长度超阈值，MySQL 仍可能跳过内存表
动态修改 vs 配置文件修改的区别和风险
动态改（SET GLOBAL）只影响新连接，已存在的连接仍用旧值；但配置文件改（my.cnf）需重启 MySQL 才生效，且会重置所有连接上下文。
- 临时调试可跑：
SET GLOBAL max_heap_table_size = 134217728;<br>SET GLOBAL tmp_table_size = 134217728;
（单位是字节，134217728 = 128M） - 但该操作不持久，MySQL 重启后丢失；生产环境务必写进
my.cnf的[mysqld]段 - 危险操作：在线 SET 过大值（如 1G+），可能瞬间耗尽剩余内存，导致后续连接失败甚至主从延迟突增
监控和验证改得有没有效
不能只看变量值，得看真实查询行为和状态计数器变化，否则等于白调。
- 关键状态变量：
Created_tmp_tables（总临时表数）、Created_tmp_disk_tables（磁盘临时表数），二者比值越低越好（理想 - 执行一次典型慢查询前后对比：
SHOW STATUS LIKE 'Created_tmp%';
观察Created_tmp_disk_tables是否减少 - 注意：某些 ORM（如 Django 的
distinct()+order_by()组合）或分页深度查询天然倾向磁盘表，这时调参数意义有限，得优化 SQL 或加覆盖索引
Created_tmp_disk_tables 的日志趋势，还有 mysql_error.log 里有没有 “Memory capacity exceeded” 类报错 —— 这些才是真实反馈。 
