直接查Created_tmp_disk_tables状态变量最准：执行GROUP BY查询后运行SHOW STATUS LIKE 'Created_tmp_disk_tables'，若值增加说明本次查询触发磁盘临时表；其与Created_tmp_tables比值超5%需警惕，且EXPLAIN中Using temporary不区分内存或磁盘，必须结合该状态变量确认。
怎么判断GROUP BY是否触发了磁盘临时表
直接查 Created_tmp_disk_tables 状态变量最准。执行完聚合查询后，运行：
SHOW STATUS LIKE 'Created_tmp_disk_tables';
如果这个值增加了，说明本次查询至少有一个临时表落盘了。注意它是个全局计数器，不是会话级的，所以高并发下要结合 SHOW PROCESSLIST 或 Performance Schema 定位具体语句。
另一个关键指标是 Created_tmp_tables，它包含内存和磁盘临时表总数。两者比值（Created_tmp_disk_tables / Created_tmp_tables）超过 5% 就该警惕。
常见误判点：EXPLAIN 中看到 Using temporary 不等于一定慢——它只表示用了内部临时表，但没告诉你用的是内存还是磁盘。必须配合状态变量才能确认实际路径。
tmp_table_size 和 max_heap_table_size 到底谁说了算
MySQL 取二者中**较小值**作为内存临时表上限。比如你设 tmp_table_size = 128M，但 max_heap_table_size = 16M，那实际阈值就是 16MB。
这两个参数必须同步调整，否则容易出现“明明调大了 tmp_table_size 却还是频繁落盘”的情况。
-
tmp_table_size控制内部临时表（如 GROUP BY、UNION）的内存上限 -
max_heap_table_size控制所有 MEMORY 引擎表（包括显式创建的临时表）的单表上限 - MySQL 8.0+ 推荐把
internal_tmp_mem_storage_engine设为TempTable，它不受max_heap_table_size限制，只看tmp_table_size
改完记得重启连接或执行 SET SESSION 生效（部分变量不支持动态 session 级修改）。
为什么加了索引，GROUP BY 还是用临时表
索引能跳过临时表的前提很严格：必须满足「松散索引扫描」——即 GROUP BY 字段是索引的**最左前缀**，且 WHERE 条件不能破坏索引有序性。
典型踩坑场景：
-
WHERE created_at > '2025-01-01' GROUP BY user_id→ 范围条件打断索引顺序，退化为紧凑扫描，仍需临时表 -
GROUP BY user_id % 10→ 表达式无法走索引，必走临时表 -
GROUP BY user_id ORDER BY COUNT(*) DESC→ 隐式排序需求，即使有索引也会触发Using filesort，常伴随临时表
验证方法：看 EXPLAIN 的 key 列是否命中索引，同时 Extra 不含 Using temporary。如果含，说明索引没被用于分组逻辑本身。
ORDER BY NULL 真的能省掉排序开销吗
能，而且效果明确。MySQL 对 GROUP BY 有默认隐式排序行为（按分组字段升序），即使你没写 ORDER BY。
加上 ORDER BY NULL 后：
- 跳过最后一步排序，减少 CPU 和临时表数据重排开销
- 如果原本因排序触发
Using filesort，现在可能只剩Using temporary（纯分组） - 在数据量大、分组键多时，性能提升可达 20%~40%
示例：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY NULL;
注意：这个优化只在你**不需要结果有序**时才安全。一旦业务依赖返回顺序，就不能加。
真正容易被忽略的是：很多 ORM 自动生成的 SQL 默认带 ORDER BY，哪怕字段为空，也可能悄悄激活排序逻辑。检查生成 SQL 的实际内容比看文档更可靠。
