因为tmp_table_size和max_heap_table_size必须同时满足，系统以二者较小值为准；若只调大其一，仍会触发磁盘临时表或ERROR 1114。
为什么 tmp_table_size 和 max_heap_table_size 调高了还是报错？
MySQL 在执行含子查询（尤其是 IN、JOIN 或派生表）的语句时，若中间结果集过大，会将内存临时表自动转存为磁盘临时表（MyISAM 或 InnoDB），但前提是满足两个阈值：必须同时不超过 tmp_table_size 和 max_heap_table_size 中的较小值。很多人只调大其中一个，结果仍触发磁盘落盘甚至 ERROR 1114 (HY000): The table 'sql_xxx' is full。
实操建议：
- 检查当前生效值：
SELECT @@tmp_table_size, @@max_heap_table_size;，确认二者是否一致；不一致时以小者为准 - 在
my.cnf中同步设置两者为相同值（例如tmp_table_size = 256M，max_heap_table_size = 256M），避免隐式截断 - 注意：该参数是会话级变量，仅对新连接生效；已存在的连接需重连或显式
SET SESSION - 调得过高可能引发 OOM（尤其在并发多、子查询密集的场景），建议结合
SHOW STATUS LIKE 'Created_tmp%';观察实际使用量再逐步调整
子查询改写成 JOIN 为什么有时反而更慢？
不是所有 IN (SELECT ...) 都适合直接改 JOIN——MySQL 优化器对子查询的物化（materialization）策略在 5.6+ 后已较成熟，而盲目改写可能破坏索引利用或引入重复行导致额外去重开销。
实操建议：
- 先用
EXPLAIN FORMAT=JSON对比原语句和改写后语句的query_block->materialized_from_subquery或join_execution->table节点，确认是否真用了物化表 - 若子查询结果集小（IN 并确保子查询字段有索引；若子查询本身可下推条件（如
WHERE user_id IN (SELECT id FROM users WHERE status=1)），把条件提到子查询内部 - 改
JOIN时务必加DISTINCT或GROUP BY防止笛卡尔膨胀，例如：SELECT DISTINCT t1.* FROM t1 JOIN (SELECT DISTINCT id FROM t2 WHERE ...) t2 ON t1.id = t2.id - 对
NOT IN，必须排除子查询含NULL的情况，否则逻辑错误；改用NOT EXISTS更安全
如何判断子查询是否真的需要物化？
MySQL 是否物化子查询，取决于能否进行“半连接”（semi-join）优化。当子查询满足关联条件、无聚合/排序/外部引用时，优化器倾向走 semi-join；否则强制物化——这时才是临时表溢出的高发点。
实操建议：
- 检查
EXPLAIN输出中select_type字段：若为DEPENDENT SUBQUERY或MATERIALIZED，说明未走 semi-join - 禁用物化强制走 semi-join（仅调试用）：
SET optimizer_switch='materialization=off';，观察执行计划是否变成FirstMatch或LooseScan - 常见破坏 semi-join 的写法：子查询里用
ORDER BY、LIMIT、GROUP BY、引用外层非关联字段、或子查询本身是UNION - 若必须保留复杂子查询逻辑，考虑拆成临时表：
CREATE TEMPORARY TABLE tmp_ids AS SELECT id FROM ...;，再JOIN tmp_ids——可控且能建索引
临时表溢出时，SHOW PROCESSLIST 看到 Copying to tmp table on disk 意味着什么？
这表示 MySQL 已放弃内存临时表，正在把数据写入磁盘（默认在 tmpdir 下生成 #sql_*.MYD/.MYI 或 #sql-*.ibd）。此时不仅慢，还可能因磁盘空间不足或 innodb_tmpdir 权限问题直接失败。
实操建议：
- 立即查磁盘剩余空间：
df -h $MYSQL_TMPDIR（注意不是/tmp，而是 MySQL 实际配置的tmpdir） - 确认
innodb_tmpdir是否指向高速存储（如 SSD），避免和系统盘混用 - 监控
Created_tmp_disk_tables增速，若远高于Created_tmp_tables，说明大量操作被迫落盘，需针对性优化 - 对无法避免的大结果集，可在 SQL 层加
SQL_BUFFER_RESULT提示（SELECT SQL_BUFFER_RESULT ...），让 MySQL 尽早释放锁并控制内存生命周期
临时表问题从来不是单点参数能根治的，关键在看清执行路径是否真需要物化、物化是否合理、以及磁盘侧有没有兜底能力。改写子查询前，先看 EXPLAIN 里的 materialized_from_subquery 和 tmp_table 字段，比盲目调参管用得多。
