tmp_table_size 与 max_heap_table_size 必须设为相同值，实际内存临时表上限取二者较小值；若不一致，调大 tmp_table_size 无效，且易致 created_tmp_disk_tables 持续增长。
tmp_table_size 和 max_heap_table_size 必须设成一样
MySQL 内存临时表的实际大小上限，取 tmp_table_size 与 max_heap_table_size 的较小值。哪怕你把 tmp_table_size 设成 256M，但 max_heap_table_size 还是默认的 16M，那临时表最多就只能用 16M 内存——调了 tmp_table_size 也白调。
常见错误现象：修改 tmp_table_size 后，SHOW VARIABLES 看起来生效了，但 Created_tmp_disk_tables 仍在持续上涨。
- 必须同步设置两者，例如都设为
67108864（64MB）或268435456（256MB） - 在线调整可用
SET GLOBAL tmp_table_size = 67108864+SET GLOBAL max_heap_table_size = 67108864，但注意：新参数只对后续新建连接生效 - 写入配置文件更稳妥：
[mysqld]\ntmp_table_size = 256M\nmax_heap_table_size = 256M
- 重启后务必验证：
SHOW VARIABLES LIKE 'tmp_table_size'和SHOW VARIABLES LIKE 'max_heap_table_size'输出值必须完全一致
EXPLAIN 出现 Using temporary 不等于要立刻调参
Using temporary 只说明优化器用了临时表来完成排序或分组，并不直接代表性能差。真正伤性能的是它落到磁盘——也就是 Created_tmp_disk_tables 持续增长。
使用场景里，ORDER BY、GROUP BY、UNION 最容易触发临时表；但如果字段有合适索引，MySQL 往往能避免建表。
- 先查监控：
SHOW GLOBAL STATUS LIKE 'Created_tmp%tables'，计算Created_tmp_disk_tables / Created_tmp_tables * 100% - 比值
- 比值 > 20%：再考虑调参，且必须配合索引优化一起做
-
SELECT DISTINCT UPPER(name)这类带函数的写法，一定走临时表，索引无效，得改逻辑
tmp_table_size 不宜超过物理内存的 10%～15%
这个参数是每个连接独占分配的。设太大，高并发下极易触发 OOM 或 swap，反而拖垮整体性能。
假设服务器 64G 内存，tmp_table_size = 1G 看似合理，但若活跃连接数达 200，理论内存占用就是 200G —— 显然不可行。
- 建议从
64M或128M起步，观察Created_tmp_disk_tables增速再逐步上调 - 结合
Threads_connected监控值估算峰值内存压力 - MySQL 8.0+ 可额外设置
internal_tmp_mem_storage_engine = TempTable，比 MEMORY 更省内存、支持变长字段 - 别忽略
tmpdir：如果必须落盘，确保它指向 SSD 或内存盘（如/dev/shm），减少 I/O 延迟
sort_buffer_size 和 tmp_table_size 完全无关
很多人混淆这两个参数。sort_buffer_size 只控制单个连接内 ORDER BY 排序时的内存缓冲区，和临时表机制无关。它对 GROUP BY 完全没作用。
增大 sort_buffer_size 可降低 Sort_merge_passes，但它不能消除 Using temporary，也不能阻止临时表落盘。
-
sort_buffer_size默认通常只有256K，对大结果集明显不够，可设为2M～8M - 它是线程独占的，总内存 =
Threads_connected × sort_buffer_size，别盲目设到几百 MB - 如果
EXPLAIN显示Using filesort，优先检查ORDER BY字段是否有覆盖索引，而不是只调这个参数
真正卡住性能的，往往不是参数数值本身，而是 tmp_table_size 和 max_heap_table_size 的不一致，以及对 Using temporary 的误判——以为出现这个词就必须调大内存，结果忽略了索引缺失这个根因。
