MySQL内存临时表上限取tmp_table_size与max_heap_table_size中较小值，二者必须设为相同值（如均为128M），否则调大tmp_table_size无效，查询仍会立即落盘至ibtmp1或/tmp导致磁盘爆满。
tmp_table_size 和 max_heap_table_size 必须同步设为相同值
这两个参数共同决定内存临时表的上限，实际生效的是其中较小的那个值。如果只调大 tmp_table_size 而忽略 max_heap_table_size，查询仍会立刻落盘——这是线上最常踩的坑。
-
tmp_table_size是全局参数，控制所有会话的默认内存临时表上限 -
max_heap_table_size是会话级参数，但必须在配置文件中设为与前者一致，否则SET SESSION修改无效（MySQL 8.0+ 默认拒绝运行时修改） - 单位支持
M、G，例如tmp_table_size = 256M，不要写成268435456这类字节数，易错且难维护 - 建议从
128M起步，再根据SHOW STATUS LIKE 'Created_tmp%'中的Created_tmp_disk_tables值逐步上调
innodb_temp_data_file_path 不能热更新，必须停库删文件再启
哪怕你只改了一行配置，MySQL 也不会重载 innodb_temp_data_file_path。旧的 ibtmp1 文件不会自动缩容，更不会被新配置覆盖——它会一直躺在 datadir 里继续膨胀。
- 操作顺序必须是：
systemctl stop mysqld→ 手动删除ibtmp1（路径通常在datadir下，不是/tmp）→ 启动服务 - 配置格式必须带分号分隔多文件，例如：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G;ibtmp2:12M:autoextend:max:2G - 单文件
ibtmp1:12M:autoextend在高并发下极易引发 I/O 锁争用，官方自 5.7 起已明确不推荐 - 验证是否生效：执行
SELECT @@innodb_temp_data_file_path;，输出必须和配置字符串完全一致（大小写、分号、单位都不能错）
internal_tmp_mem_storage_engine 推荐设为 TempTable
MySQL 8.0 默认用 TempTable 引擎管理内部临时表（如 GROUP BY、ORDER BY 中间结果），它比老式 MEMORY 更省内存、支持变长字段，且不会因 BLOB/TEXT 字段强制落盘。
- 显式配置
internal_tmp_mem_storage_engine = TempTable可避免部分场景下意外降级到磁盘 - 该参数不影响用户创建的
CREATE TEMPORARY TABLE，只管优化器生成的内部临时结构 - 搭配
tmp_table_size使用才有意义；若后者太小，TempTable也会退回到磁盘 - 不要和
innodb_temp_data_file_path混淆：前者管内存引擎行为，后者只管共享临时表空间文件
phpEnv 或其他打包环境要手动改 my.ini，重启服务≠重载配置
很多 Windows 用户用 phpEnv，点控制面板里的“Restart MySQL”根本不会触发配置文件重读——它只是发个 SIGTERM 再拉起进程，旧 ibtmp1 照样残留，新配置压根不生效。
- 路径通常是
C:\phpEnv\MySQL\my.ini，编辑时只改[mysqld]段，别误加到[client]或[mysql] - 必须右键 phpEnv 图标 → “Restart MySQL Service”，不是“Restart phpEnv”
- Linux 下若用 systemd，确保
mysqld.service没被覆盖或禁用LimitNOFILE等限制，否则大临时表可能直接报Operating system error number 23 - 改完别只看文件大小，用
SELECT * FROM information_schema.INNODB_TEMP_TABLE_INFO;查当前活跃临时表更准——ibtmp1文件大 ≠ 正在用得多
真正卡住性能的往往不是参数没设对，而是 ibtmp1 文件长期不清理 + Created_tmp_disk_tables 持续上涨却没人查慢查询日志。临时表问题从来不是单点配置能解决的，它暴露的是索引缺失、排序字段无覆盖、JOIN 条件未走索引这类更底层的设计问题。
