临时表溢出需四步协同解决：先查@@tmpdir、df -h和Created_tmp_disk_tables占比确认根源；再同步设置tmp_table_size与max_heap_table_size相等；接着规避ORDER BY/GROUP BY含函数、类型不匹配等落盘写法；最后控制innodb_buffer_pool_size≤80%物理内存并预留系统余量。
临时表溢出不是配置调大就能解决的表象问题，而是内存参数、SQL写法和磁盘路径三者失配的综合信号。盲目增大 tmp_table_size 可能加速 OOM，或把压力转嫁给根分区；真正有效的调优，得从确认根源、对齐参数、规避落盘诱因、控制总内存四方面入手。
先确认是不是临时表真占满了磁盘
别一看到 “The table is full” 或 /tmp 分区 100%，就改配置。先做三件事：
- 查 MySQL 实际用的临时目录：
SELECT @@tmpdir;，再用df -h看对应挂载点使用率 - 查状态变量：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';和Created_tmp_tables，若前者占比超 10%，说明大量查询被迫落盘 - 用
lsof +D /path/to/tmpdir（替换为上一步查到的真实路径）看哪些 PID 正在往里面写大文件，排除日志、备份等非 MySQL 进程干扰
必须让 tmp_table_size 和 max_heap_table_size 相等
MySQL 内存临时表大小取两者最小值。只调 tmp_table_size 而忽略 max_heap_table_size（默认常为 16MB），等于白调。
- 在
/etc/my.cnf的[mysqld]段中显式设为相同值，例如：tmp_table_size = 256M和max_heap_table_size = 256M - 重启前执行
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size';，确认两者一致且生效 - 混跑 OLTP + 报表的实例，建议按峰值报表 SQL 中间结果大小来定，宁高勿低，但别超物理内存的 20%
减少 ORDER BY / GROUP BY 强制落盘的写法
即使内存参数调得再大，SQL 写法踩坑照样生成磁盘临时表。
-
ORDER BY字段必须与WHERE条件共用同一索引的最左前缀，否则大概率落盘 -
GROUP BY后字段若含函数（如DATE(created_at)、JSON_EXTRACT(col, '$.name')）或类型不匹配（如BIGINT列传字符串值），无法走索引，强制物化 - 避免视图里嵌套
GROUP BY或ORDER BY；EXPLAIN 出现DERIVED+Using temporary就是典型信号 - 删掉
SELECT *，只查业务真正需要的字段，尤其避开TEXT、BLOB等大字段参与排序或分组
控制 MySQL 总内存上限，防 OOM 杀进程
当 mysqld 被系统 OOM Killer 杀掉时，说明不是 MySQL 自己报错，而是系统级内存不足——此时调单个参数没用，得保命。
-
innodb_buffer_pool_size建议设为物理内存的 70%～80%，且预留至少 2GB 给系统和其他进程 - 注意 per-connection 缓冲区叠加效应：
sort_buffer_size、join_buffer_size、tmp_table_size都是每个连接独占，乘以max_connections后可能远超预期 - 监控
Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值，低于 95% 表示缓冲池效率偏低，可考虑适度加大 - 小内存机器（≤2GB）慎设大 buffer pool；顺手清理已弃用的
query_cache_size等残留配置
