必须设为相等，因为MySQL 5.7中内存临时表上限取tmp_table_size与max_heap_table_size的较小值，若不一致（如前者256M、后者默认16M），实际仍按16M截断，导致超限查询强制落盘至磁盘临时表，引发I/O飙升和/tmp或ibtmp1爆满。
为什么 tmp_table_size 和 max_heap_table_size 必须设为相等
MySQL 5.7 中，内存临时表的大小受两个参数共同限制：tmp_table_size 控制 CREATE TEMPORARY TABLE 或隐式内部临时表（如 GROUP BY、ORDER BY）能使用的最大内存；max_heap_table_size 则限制 HEAP 引擎表（包括显式创建的 MEMORY 表）的上限。当二者不一致时，MySQL 以**较小值为准**——如果 tmp_table_size 是 64M 而 max_heap_table_size 是 16M，那所有内存临时表实际最多只能用 16M，超出即落盘成 MYISAM 临时表，引发磁盘 I/O 和 /tmp 目录膨胀。
实操建议：
- 在
my.cnf中显式设为相同值，例如：tmp_table_size = 256M<br>max_heap_table_size = 256M
- 修改后需重启 MySQL（5.7 不支持动态修改这两个参数）
- 确认生效：执行
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size';，确保输出一致
如何定位哪些查询正在生成大量临时表
不能只看 Created_tmp_tables 累计值，它包含所有临时表（含合理小表）。关键指标是 Created_tmp_disk_tables —— 只有落到磁盘的才真正危险。当该值持续增长，说明内存不足或查询写法低效。
开启慢日志并捕获临时表相关行为：
- 设置
long_query_time = 1，并启用log_queries_not_using_indexes = OFF（避免干扰） - 添加
log_slow_slave_statements = ON（若用从库做分析） - 重点过滤含
Using temporary的执行计划：对慢日志中每条 SQL 执行EXPLAIN FORMAT=TRADITIONAL，检查Extra字段是否出现该提示 - 典型高危模式：
GROUP BY非索引列、ORDER BY+LIMIT混用且无覆盖索引、多表 JOIN 后聚合
GROUP BY 查询为什么总触发临时表，怎么改写
MySQL 5.7 默认使用 SQL_MODE=ONLY_FULL_GROUP_BY，但更关键的是：即使语义合法，只要 GROUP BY 字段未被索引覆盖，优化器大概率选择排序 + 临时表路径，而非松散索引扫描。
优先尝试的改写方式：
- 确保
GROUP BY列上有**前缀匹配的复合索引**，例如SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;应建INDEX(user_id)或INDEX(user_id, status) - 避免
SELECT *后GROUP BY，只选必要字段，减少临时表行宽 - 用
WHERE提前过滤，缩小输入集（如加时间范围），比在大结果上分组更有效 - 极端情况可考虑用
UNION ALL分片聚合再合并，绕过单次大临时表
注意：SQL_BUFFER_RESULT 提示对临时表无实质帮助，它只把结果集缓存在服务端内存中，不改变执行计划。
临时表文件没清理干净，/tmp 占满怎么办
MySQL 5.7 在崩溃或异常退出时，可能遗留 #sql_* 开头的临时文件（如 #sql_3a9c_1.MYD），这些不是运行时临时表，而是 ALTER TABLE 等 DDL 操作中途失败留下的残骸，mysqld 不会自动清理。
安全清理步骤：
- 先确认 MySQL 已完全停止：
systemctl is-active mysql返回inactive - 进入
tmpdir（默认/tmp，可通过SHOW VARIABLES LIKE 'tmpdir';查看），列出疑似残留文件：ls -lt /tmp/#sql_* - 只删除修改时间早于 MySQL 最后启动时间的文件（用
systemctl status mysql | grep "Started"查启动时间） - 切勿删除
ibtmp1或以mysql-bin.开头的文件——它们不属于临时表范畴
长期预防：将 tmpdir 改到独立分区（如 /var/tmp/mysql），并配置 tmp_table_size 合理上限，避免单次查询耗尽整个 /tmp。
