MySQL不会报tmp_table_size超限错误，而是查询变慢、Created_tmp_disk_tables飙升，慢查日志出现Using temporary; Using filesort；调大需同步设置max_heap_table_size，且受字段类型、索引、连接时效等影响。
tmp_table_size 超了会报什么错
MySQL 不会直接报 tmp_table_size 超限的错误，但你会看到查询变慢、磁盘临时表暴增，甚至触发 Created_tmp_disk_tables 指标飙升。更典型的线索是慢查日志里出现 Using temporary; Using filesort，同时 SHOW STATUS LIKE 'Created_tmp%' 显示 Created_tmp_disk_tables 占比持续高于 10%——这说明内存临时表不够用，被迫落盘。
怎么安全调大 tmp_table_size
不能只改 tmp_table_size，它必须和 max_heap_table_size 同步调整，否则以二者中较小值为准。线上调优建议按以下顺序操作：
- 先查当前值：
SELECT @@tmp_table_size, @@max_heap_table_size; - 确认可用内存余量（别让单个连接吃光 2GB 内存），建议单次调幅 ≤ 256MB
- 动态生效（仅对新连接）：
SET GLOBAL tmp_table_size = 268435456;和SET GLOBAL max_heap_table_size = 268435456; - 写入配置文件（
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf）持久化：[mysqld] tmp_table_size = 268435456 max_heap_table_size = 268435456
为什么调了还是走磁盘临时表
常见原因不是参数没生效，而是查询本身不满足内存表条件：
- 字段含
TEXT或BLOB类型 → 强制走磁盘，无论tmp_table_size多大 - 使用了
UNION、DISTINCT、GROUP BY+ 非索引列 → 容易突破内存限制 - 客户端连接时已建立，
SET GLOBAL不影响旧连接，得重连或用SET SESSION单独设 -
innodb_buffer_pool_size过小导致整体内存紧张，系统主动回收临时表内存
tmp_table_size 对不同存储引擎的影响
这个参数只控制 MEMORY 引擎临时表的上限，和 InnoDB 或 MyISAM 无关。但要注意：
- InnoDB 查询中产生的内部临时表（如排序、聚合）仍受此值约束，只是底层可能用 InnoDB 格式落盘
- MyISAM 临时表完全绕过
tmp_table_size，直接写磁盘，所以调大该值对 MyISAM 场景无效 - 如果
internal_tmp_mem_storage_engine设为TempTable（MySQL 8.0.13+ 默认），则受temp_table_max_ram控制，而非tmp_table_size
真正卡住性能的往往不是单个参数值，而是查询是否能避免生成大临时表——比如加索引覆盖 GROUP BY 字段，比盲目调高 tmp_table_size 更有效。参数只是兜底，不是解药。
