mysql 5.7临时表性能瓶颈不在索引，而在tmp_table_size与max_heap_table_size不匹配导致频繁落盘及ibtmp1单文件无上限暴涨；二者必须设为相等并重启生效，且ibtmp1已涨大需重启才能重置。
MySQL 5.7 的临时表索引性能在高并发下不会成为“全局瓶颈”——真正卡住的是 tmp_table_size 和 max_heap_table_size 不匹配导致的磁盘落盘风暴，以及 ibtmp1 文件无上限暴涨引发的 I/O 阻塞。
为什么临时表“建索引”不是问题，落盘才是
临时表本身不走 Buffer Pool，也不走持久化索引路径。InnoDB 临时表（CREATE TEMPORARY TABLE）的索引是内存结构，创建快、销毁快，不涉及刷脏页或 WAL 写入。真正拖慢高并发的，是临时结果集超限后强制落盘到 ibtmp1 或 /tmp，触发大量随机写和文件锁竞争。
- EXPLAIN 看到
Using temporary+Using filesort时，若Created_tmp_disk_tables暴涨，说明已在刷磁盘 - 每个线程独立生成临时表，但
ibtmp1是全局共享文件，多线程并发写同一文件会争抢 file mutex -
ibtmp1默认配置为ibtmp1:12M:autoextend，无:max:限制，写满根分区是常见事故
innodb_temp_data_file_path 配置不当放大 I/O 竞争
MySQL 5.7 默认只用单个 ibtmp1 文件承载所有临时表数据，高并发下极易成为 I/O 热点。即使你调大了 tmp_table_size，只要没配 innodb_temp_data_file_path 多文件分片，所有线程仍挤在同一个文件上。
- 正确做法：设为
ibtmp1:12M:autoextend:max:2G;ibtmp2:12M:autoextend:max:2G，让 InnoDB 自动轮询分配 - 注意：该参数**不可动态修改**，必须重启生效；且文件数不能超过
innodb_page_size / 4KB（默认 64 个） - 如果已看到
SHOW ENGINE INNODB STATUS\G中大量FILE I/O等待，基本确认是ibtmp1单点写瓶颈
临时表索引失效常被误判为“索引问题”
临时表上的索引查得慢，往往不是索引本身不行，而是查询计划根本没走它——因为优化器在内存受限时会降级执行策略，甚至放弃使用索引直接扫描。
- 临时表字段没统计信息（
ANALYZE TABLE对临时表无效），优化器只能靠粗略估算，容易选错执行路径 - 如果
tmp_table_size设为 64M，但某次 GROUP BY 结果实际占 80M，InnoDB 会先建内存表+索引，再整体 dump 到磁盘，此时索引白建 - 验证方式：开
optimizer_trace，查steps中considered_execution_plans是否包含索引访问路径
最常被忽略的一点：调大 tmp_table_size 前，必须同步改 max_heap_table_size，否则阈值还是 16M；而改完之后，ibtmp1 已膨胀的部分无法在线回收，必须重启才能重置——这点不提前规划，高并发压测时可能直接触发 OOM killer。
