调大 tmp_table_size 有时无效，因其实际限制取 tmp_table_size 与 max_heap_table_size 的较小值；仅调一个参数无效，需同步调整二者，并注意 text/blob 字段强制走磁盘临时表。
为什么调大 tmp_table_size 有时没用？
因为 tmp_table_size 只控制内存临时表的上限，但它必须和 max_heap_table_size 同时生效——MySQL 会取两者中**较小值**作为实际限制。只改一个，另一个仍卡在默认 16MB（或更低），结果就是临时表照常落盘，错误照旧报。
常见错误现象：ERROR 1114 (HY000): The table is full 或日志里出现 Copying to tmp table 状态持续很久。
- 检查当前值：
SELECT @@tmp_table_size, @@max_heap_table_size; - 动态调整（会话级）：
SET SESSION tmp_table_size = 268435456;和SET SESSION max_heap_table_size = 268435456;（256MB） - 永久生效需在
[mysqld]段统一配置，且重启或热加载（如支持）才生效
tmp_table_size 设多大才算合理？
不是越大越好。过大的值会导致单个查询占用过多内存，挤占缓冲池（innodb_buffer_pool_size）或引发 OOM；太小又频繁落盘，性能陡降。关键看你的典型查询中间结果集大小。
使用场景参考：
- 简单
GROUP BY或ORDER BY（无索引）：64–128MB 通常够用 - 带
UNION或多层子查询的报表类 SQL：建议 256–512MB，但要监控Created_tmp_disk_tables状态变量是否明显下降 - RDS 实例（如阿里云）：注意
loose_rds_max_tmp_disk_space限制（默认 10GB），即使内存够，磁盘临时表总量超限仍会报错
改了参数还是报错？先确认临时表到底落哪了
MySQL 默认优先用内存，超限后自动转磁盘临时表——但磁盘位置、空间、引擎都可能成为瓶颈。不能只盯着 tmp_table_size。
排查要点：
- 查当前临时目录：
SELECT @@tmpdir;，然后df -h看该路径所在分区剩余空间 - 确认是否被
ibtmp1占满（MySQL 5.7+）：它存放磁盘临时表的 undo 日志，不随重启自动收缩，需停库 + 删除（风险高）或升级到 8.0.30+ 启用innodb_temp_data_file_path自动管理 - 检查是否用了
TEXT/BLOB字段：这类字段强制走磁盘临时表，tmp_table_size完全无效
比调参更有效的三件事
参数是兜底手段，根源往往在 SQL 本身。以下操作见效更快、风险更低：
- 给
GROUP BY/ORDER BY字段加联合索引，让 MySQL 能直接利用索引排序，跳过临时表 - 用
EXPLAIN FORMAT=tree（MySQL 8.0+）看执行计划里是否有Using temporary；若有，尝试拆分复杂UNION或用物化 CTE（WITH ... AS MATERIALIZED）控制中间结果 - 避免在大表上
SELECT DISTINCT或COUNT(DISTINCT)，改用近似函数APPROX_COUNT_DISTINCT()（MySQL 8.0.19+）或预聚合表
真正容易被忽略的是：很多“临时表满了”问题，其实发生在凌晨备份或统计任务期间，此时 tmpdir 被其他进程（如 mysqldump、logrotate）临时占满，而非 MySQL 自身配置不足。
