GROUP BY出现Using temporary时，盲目调sort_buffer_size无效，因其仅影响排序不控制临时表；真正应同步调大tmp_table_size和max_heap_table_size并优先建匹配联合索引。

GROUP BY 出现 Using temporary 就别乱调 sort_buffer_size

sort_buffer_size 和 GROUP BY 是否用临时表完全无关。它只在需要排序时（比如 ORDER BY 或 GROUP BY ... ORDER BY）为每个连接单独分配内存，不控制临时表大小、不决定落盘与否。盲目调大它既不能消除 Using temporary，也不能防止磁盘临时表生成，纯属浪费内存。

真正管临时表的是 tmp_table_size 和 max_heap_table_size

这两个参数共同决定内存临时表的上限：MySQL 取二者中较小值作为阈值。一旦 GROUP BY 中间结果超过该值，就会从 MEMORY 引擎退化为磁盘临时表（InnoDB/MyISAM），I/O 暴增，查询变慢。

• 必须同时设置且数值一致，例如都设为 67108864（64MB）
• 设太高可能挤占其他连接内存；设太低（如默认 16MB）在千万级分组时极易落盘
• MySQL 8.0+ 可配合 internal_tmp_mem_storage_engine=TempTable 提升内存表效率

EXPLAIN 里看到 Using temporary，优先检查索引而非参数

临时表是症状，不是病因。Using temporary 的根本原因是 MySQL 无法利用索引完成分组——比如缺少联合索引、字段顺序错、或 SELECT 了非聚合列导致无法覆盖。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 建索引要严格按 WHERE 条件 + GROUP BY 字段顺序，例如 SELECT COUNT(*) FROM t WHERE status=1 GROUP BY category, type 应建 INDEX(status, category, type)
• SELECT * 或 SELECT name, COUNT(*)（name 不在索引里）会强制回表甚至放弃索引
• 用 EXPLAIN FORMAT=TRADITIONAL 看 Extra 列，确认是否真有 Using temporary，再决定是否动参数

什么时候才该动临时表参数？

仅当已确认索引合理、查询结构精简、且 Created_tmp_disk_tables 明显偏高（比如占 Created_tmp_tables 的 20% 以上）时，才考虑调参。

• 先查监控：SHOW STATUS LIKE 'Created_tmp%tables';
• 观察 tmpdir 所在磁盘 I/O 是否持续高位，这是落盘的直接证据
• 调参后必须验证：执行原 SQL 并对比 EXPLAIN 的 Extra 是否仍含 Using temporary —— 如果还在，说明问题根本不在内存限制上

索引没建对，参数调到 2GB 也白搭；索引建对了，多数场景连默认 16MB 都用不完。