合理使用mysql临时表可提升性能，核心是减少磁盘写入与内存滥用。通过索引优化GROUP BY、ORDER BY，避免using filesort；控制字段数量，用JOIN替代子查询；设置tmp_table_size和max_heap_table_size一致（如64M~256M），防止落盘；利用EXPLaiN检查Using temporary和Using filesort，结合慢查询日志定位问题SQL；MySQL 8.0+使用InnoDB存储磁盘临时表更稳定；必要时显式创建带索引的临时表以提高可控性。
在MySQL中，临时表常用于复杂查询中的中间结果存储。合理使用能提升性能，但滥用或配置不当会导致资源浪费和响应变慢。优化临时表的核心是减少磁盘写入、控制内存使用，并避免不必要的创建。
理解临时表的存储机制
MySQL在执行某些select语句（如包含GROUP BY、DISTINCT、union或子查询）时会自动创建内部临时表。这些表可能先在内存中（使用Memory引擎），当数据量超过限制时会转为磁盘存储（如MyISAM或InnoDB）。磁盘临时表显著降低查询速度。
关键参数包括：
- tmp_table_size：单个线程内存临时表的最大大小
- max_heap_table_size：影响MEMORY引擎表的上限，也作用于临时表
如果临时表超出这两个值中的较小者，就会被转换为磁盘表。建议将两者设为相同值，避免意外落盘。
通过索引和查询改写减少临时表开销
很多临时表的生成源于无法高效处理排序或去重。优化手段包括：
- 确保GROUP BY和ORDER BY涉及的列有合适索引，避免文件排序（Using filesort）
- 尽量减少SELECT *，只取必要字段，降低临时表行大小
- 用JOIN替代子查询，有时可绕过临时表创建
- 对大结果集的DISTINCT操作，考虑是否可通过业务逻辑前置去重
例如，以下查询容易触发临时表： SELECT DISTINCT user_id FROM log WHERE date > ‘2024-01-01’;
若user_id已有索引，可利用索引扫描避免临时表；否则可考虑添加联合索引(date, user_id)提升效率。
监控和识别问题查询
使用EXPLAIN分析执行计划，关注Extra字段中的提示：
- Using temporary：明确表示使用了临时表
- Using filesort：可能伴随临时表使用
结合慢查询日志（slow_query_log），定位频繁创建磁盘临时表的SQL。设置long_query_time并开启log_queries_not_using_indexes有助于发现低效语句。
合理配置和权衡资源
根据服务器内存情况调整参数，但不要盲目调大：
- tmp_table_size 和 max_heap_table_size 可设为 64M~256M，视可用内存而定
- 注意每个连接独立使用该限制，高并发下总内存消耗可能很高
- MySQL 8.0+默认使用InnoDB作为磁盘临时表引擎，更稳定且支持崩溃恢复
若应用确实需要大量临时数据处理，考虑将中间结果存入显式创建的临时表，并为其添加必要索引，反而比隐式临时表更可控。
基本上就这些。重点是让查询走索引、减少数据量、控制内存使用，再配合监控调优，就能有效降低临时表带来的性能负担。