using temporary不是错误，而是mysql因无法用索引直接完成排序或分组而创建临时表；真正影响性能的是是否落盘，由tmp_table_size与max_heap_table_size中较小值决定，二者必须同步调大至64mb–256mb并监控created_tmp_disk_tables占比低于5%，根治方法是建立覆盖索引。
嵌套查询本身不直接触发 tmp_table_size 限制，但子查询结果集参与外层 GROUP BY / DISTINCT / ORDER BY 时，极易突破内存阈值导致落盘——调 tmp_table_size 之前，必须先确认它真被用上了。
查执行计划：Using temporary 出现在哪一层？
嵌套查询（比如 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 ...)）是否走临时表，取决于子查询是否被物化（materialized），而物化与否又由优化器决定。MySQL 5.7+ 默认尝试将子查询转为 semi-join，不建临时表；但一旦加了 ORDER BY、GROUP BY 或 LIMIT 等，就大概率强制物化。
- 运行
EXPLAIN FORMAT=tree（MySQL 8.0+）或EXPLAIN，重点看最外层或子查询节点的Extra列是否含Using temporary - 若只在子查询行出现
Using temporary，说明物化发生在内层，且其结果要参与后续操作——这时才受tmp_table_size约束 - 若外层还有
Using filesort+Using temporary，往往是嵌套结果集太大，排序+聚合双杀，内存根本扛不住
为什么只调 tmp_table_size 常常无效？
因为内存临时表实际大小取 tmp_table_size 和 max_heap_table_size 的较小值。线上常见配置是前者设成 256M，后者仍为默认 16M，结果还是卡死在 16M。
- 必须同步设置：
tmp_table_size = 256M且max_heap_table_size = 256M - 修改后需重启 MySQL 或用
SET GLOBAL（注意权限及对已有连接无效） - 验证是否生效：连上后执行
SHOW VARIABLES LIKE 'tmp_table_size'; SHOW VARIABLES LIKE 'max_heap_table_size';，两个值必须完全一致 - 若仍见大量
Created_tmp_disk_tables，说明不是参数问题，而是 SQL 本身结构导致无法避免落盘（如含TEXT字段）
比调参更关键的三件事：让嵌套不生成大中间集
临时表是“不得已的补救”，不是设计目标。嵌套查询性能差，根因往往在数据访问路径没对齐。
- 把子查询改写为
JOIN：尤其当子查询有索引字段可关联时，IN (SELECT ...)很可能比INNER JOIN多一次全表扫描 - 给子查询的
WHERE条件和外层GROUP BY字段建联合索引，让优化器有机会跳过物化，直接流式处理 - 拆分嵌套：例如将
SELECT * FROM t1 WHERE x IN (SELECT y FROM t2 WHERE ...)拆成两步，先查出 y 值存入临时表（显式命名、加索引），再 JOIN——可控、可监控、不依赖优化器猜测
注意 TEXT/BLOB 字段这个“隐形杀手”
只要查询结果或中间物化集里包含任何 TEXT 或 BLOB 类型字段，MySQL 会直接放弃内存临时表，强制走磁盘——此时 tmp_table_size 完全失效。
- 检查
EXPLAIN输出中select_type为DERIVED或MATERIALIZED的行，看其table列是否引用了含大字段的表 - 临时方案：子查询中显式排除
TEXT/BLOB字段，只 SELECT 关键 ID 或索引列 - 长期方案：考虑用生成列（generated column）或冗余摘要字段替代原始大字段参与聚合
真正难处理的从来不是参数数字，而是嵌套逻辑里那些没被索引覆盖的字段组合、不可预测的物化时机，以及 TEXT 字段带来的“一票否决”。参数只是兜底，别让它成为你忽略 SQL 结构的借口。
