如果你正在从MySQL 5.7版本升级到8.0，可能会遇到一个关键参数“消失”的情况：那就是tmp_table_size。这个曾经用于控制内存临时表大小的参数在MySQL 8.0中已被正式移除。现在，决定临时表是否写入磁盘的核心机制，取决于max_heap_table_size与internal_tmp_mem_storage_engine这套新的组合控制策略，同时也与SQL查询语句本身的复杂度和数据特性密切相关。

升级后最常遇到的第一个困惑就是：你无法再查询或设置tmp_table_size了。即使在MySQL配置文件中保留了该参数，MySQL 8.0也会在重启时静默忽略它，且不会产生任何错误提示，这容易导致配置误解。

为什么查询 SHOW VARIABLES LIKE 'tmp_table_size' 会找不到或返回 0？

根本原因在于，tmp_table_size参数在MySQL 8.0的架构中已经不复存在。如果你是从旧版本升级而来，残留在配置文件（如my.cnf）中的tmp_table_size设置项会被MySQL直接忽略，不会生效。

• 执行SELECT @@tmp_table_size通常会返回0，在某些情况下甚至会直接报错，提示“Unknown system variable”。
• 正确的做法是查询新的相关变量：SHOW VARIABLES LIKE 'internal_tmp%'，其中需要重点关注internal_tmp_mem_storage_engine这个核心参数。
• 升级完成后，务必清理配置文件中的过时参数项，避免产生参数已生效的误判，影响后续性能调优。

如何有效诊断临时表是否频繁写入磁盘？

判断临时表落盘情况，不能只看单一数值，关键在于分析比例。可以通过以下两个全局状态变量进行精准评估：

• SHOW GLOBAL STATUS LIKE 'Created_tmp_tables'：统计在内存和磁盘上创建的所有临时表的总数量。
• SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'：统计其中因超出内存限制而不得不写入磁盘的临时表数量。

计算磁盘临时表占比公式：Created_tmp_disk_tables / Created_tmp_tables。如果该比例持续超过5%，就需要开始关注；若超过15%，则表明临时表落盘已成为显著的数据库性能瓶颈，急需优化。

这里有一个重要的技术细节：这些状态统计对于新建立的数据库连接是实时生效的，但已存在的旧连接会继续沿用其连接建立时的内存引擎和限制设置。因此，在调整相关参数后，建议观察10到30分钟，待新连接占比提升后再评估优化效果，这样数据更具代表性。

应该调整哪些参数？如何设置才能安全有效？

在MySQL 8.0中，控制内存临时表的核心是两个参数，且建议将它们设置为相同的数值以保持一致性：

• max_heap_table_size：此参数定义了MEMORY引擎表和内存临时表的最大容量上限，同时也约束着TempTable引擎的内存使用量。
• internal_tmp_mem_storage_engine：在MySQL 8.0中，此参数默认值为TempTable。TempTable引擎相比传统的MEMORY引擎更节省内存，并且原生支持BLOB/TEXT等大字段类型，通常不建议将其改回MEMORY。

具体操作与配置建议：

• 首先，查看当前参数值：SELECT @@max_heap_table_size, @@internal_tmp_mem_storage_engine;
• 根据服务器内存容量和业务负载，适当上调max_heap_table_size。例如，将其从默认的16MB调整到256MB：SET GLOBAL max_heap_table_size = 268435456;
• 为确保MySQL服务重启后配置不丢失，必须将调整后的参数写入配置文件（例如/etc/mysql/mysql.conf.d/mysqld.cnf）：

[mysqld]
max_heap_table_size = 268435456
internal_tmp_mem_storage_engine = TempTable

至于tmpdir（临时文件目录）或innodb_temp_data_file_path（InnoDB临时表空间文件）这些参数，它们定义了磁盘临时表的最终存储路径，属于最后的“退路”。我们进行参数优化的核心目标，正是尽可能让临时表在内存中处理，避免使用到这些磁盘路径。

为什么参数调大后仍然出现磁盘临时表？

即使已经调大了内存参数，磁盘临时表依然可能出现。这往往不是参数设置问题，而是由于查询语句的特性绕过了内存限制：

• 当SQL查询包含没有索引的GROUP BY或ORDER BY子句时，排序操作无法在内存中高效完成，优化器可能会直接选择使用磁盘临时表。
• 查询中如果涉及TEXT、BLOB或超大VARCHAR字段，即使总数据量未超过max_heap_table_size限制，TempTable引擎出于内部存储管理的考虑，也可能主动选择落盘。
• 在高并发场景下，单个数据库连接同时执行多个大型复杂查询，内存会被复用和竞争，可能触发内部降级机制，导致临时表写入磁盘。
• 需要深刻理解：max_heap_table_size是单个连接中内存临时表的上限，但服务器实际能分配的总内存，是此值与（max_connections * max_heap_table_size）以及服务器物理可用内存之间的动态平衡。将单个连接的值设置得过大（例如超过2GB），可能导致服务器内存被快速耗尽，引发更严重的系统问题。

归根结底，解决MySQL临时表性能问题的有效策略永远是“双管齐下”：调整参数是“治标”的快速手段，能够缓解症状；而优化SQL语句（例如为分组和排序字段添加合适索引、拆分嵌套过深的子查询、避免使用SELECT *而只选择必要字段）才是“治本”的长远之计。只依赖参数调整，往往只是扬汤止沸，无法根除性能瓶颈。