MySQL用内存还是磁盘临时表取决于tmp_table_size与max_heap_table_size的较小值；若超此值或含BLOB/TEXT、UNION、DISTINCT等操作则强制落盘。

tmp_table_size 和 max_heap_table_size 到底谁说了算？

MySQL 用内存临时表还是磁盘临时表，不是看 tmp_table_size 单独决定的，而是取 tmp_table_size 和 max_heap_table_size 的**较小值**。这个细节被很多人忽略，结果调大了 tmp_table_size 却没效果，因为 max_heap_table_size 还卡在默认的 16MB。

• tmp_table_size 是会话级变量，只影响当前连接；max_heap_table_size 既是全局变量，也支持会话级设置，但它的会话值不能超过全局值
• 如果执行 SELECT ... GROUP BY 或 ORDER BY 时需要临时表，且估算大小超过这个“较小值”，MySQL 就会退到磁盘（MyISAM 或 InnoDB 临时表）
• 注意：即使你把两个值都设得很大，如果查询本身涉及 BLOB/TEXT 列，或者用了 UNION、DISTINCT 等操作，MySQL 也会直接走磁盘——这是硬限制，和内存阈值无关

怎么确认你的查询到底用了内存还是磁盘临时表？

别猜，用 SHOW STATUS LIKE 'Created_tmp%' 看实时计数，再结合 EXPLAIN FORMAT=JSON 查 using_temporary_table 字段是否为 true，以及 estimated_row_count 和 memory_used（如果有的话）。

• Created_tmp_tables：所有临时表总数（含内存+磁盘）
• Created_tmp_disk_tables：明确落到磁盘的临时表数量 —— 这个值升高，说明你的阈值可能不够或查询设计触发了强制落盘
• 执行前先 FLUSH STATUS，再跑目标 SQL，能更干净地观察单条语句行为
• 注意：information_schema.PROCESSLIST 里看不到临时表类型，performance_schema.events_statements_current 也只记是否用了临时表，不区分介质

heap_table_size 不是独立配置项，别被名字骗了

没有叫 heap_table_size 的系统变量 —— 这是个常见误写。实际只有 max_heap_table_size。有人在配置文件里写了 heap_table_size = 64M，MySQL 启动时会静默忽略它，既不报错也不生效。

• 检查配置是否生效，用 SELECT @@global.max_heap_table_size, @@session.max_heap_table_size，而不是靠 grep 配置文件
• 动态修改必须用 SET GLOBAL max_heap_table_size = 67108864（单位字节），不能写 64M —— MySQL 不识别带单位的字符串赋值
• 修改后新连接才能继承新全局值；已有连接的会话值不变，除非显式 SET SESSION max_heap_table_size = ...

为什么调大了阈值，慢查询还是没改善？

临时表只是瓶颈之一。即使成功留在内存，如果排序字段没索引、GROUP BY 的列基数太高、或者结果集本身巨大，CPU 和内存带宽照样吃紧。更关键的是：内存临时表用的是 MEMORY 引擎，不支持 BLOB/TEXT，也不支持 FULLTEXT 索引，一旦字段类型或操作越界，就必然切到磁盘。

• 常见触发磁盘的“隐形条件”：SELECT DISTINCT ... ORDER BY、UNION ALL 以外的 UNION、任何包含 TEXT 列的 GROUP BY
• tmp_table_size 和 max_heap_table_size 调太大也有代价：每个连接都可能独占一块内存，容易引发 OOM，尤其在连接数高的场景
• 真正治本的方式往往是优化 SQL：加索引覆盖排序/分组字段、拆分复杂子查询、避免 SELECT * 带回多余列

阈值切换不是黑盒开关，它依赖 MySQL 对中间结果的粗略估算，而估算本身可能不准。所以观察 Created_tmp_disk_tables 变化比死盯配置值更有意义。另外，5.7 和 8.0 在临时表引擎选择逻辑上有差异，升级后记得重新验证。