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 在临时表引擎选择逻辑上有差异，升级后记得重新验证。
