InnoDB buffer_pool_size设过高是OOM主因，非不足而是抢占过多内存；应按free -h的available值设为≤70%（单机）或≤50%（混合部署），并配合合理调优per-thread缓冲、tmp_table_size及max_connections避免乘积效应超限。
innodb_buffer_pool_size设太高是主因，不是“不够用”而是“抢光了”
绝大多数复杂SQL引发的OOM，根本不是buffer pool太小，而是它占得太多，挤占了系统和其他MySQL组件的内存空间。比如你查一个带多表JOIN和ORDER BY的大表，InnoDB缓存占了14G，而系统总共才16G，剩下2G要分给sort_buffer、临时表、OS缓存、SSH、监控Agent……OOM Killer随时可能杀掉mysqld进程。
实操建议：
- 用
free -h看available值（不是total），这是真正能分给MySQL的上限 - 单机纯MySQL：设为
available的≤70%；混合部署（如Docker+MySQL+Nginx）：必须≤50% - 别写
innodb_buffer_pool_size = 12G，改用字节值并加注释，例如innodb_buffer_pool_size = 8589934592 # 8G, based on free -h available=11G - 改完配置后，用
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep buffer_pool确认没被systemd或启动脚本覆盖
sort_buffer_size全局调大反而加速OOM，该用会话级临时设置
复杂查询里出现Using filesort时，很多人第一反应是把sort_buffer_size从默认256KB拉到256MB——这等于每个连接都预占256MB，10个并发就吃掉2.5G，完全无视实际是否真需要排序。
实操建议：
- 先用
EXPLAIN SELECT ... ORDER BY ...确认Extra列是否真有Using filesort；没有就说明索引已覆盖，调buffer毫无意义 - 有filesort时，优先建复合索引，比如
ORDER BY status, created_at→CREATE INDEX idx_status_created ON t(status, created_at) - 必须调时，用
SET SESSION sort_buffer_size = 4194304（4MB）临时生效，而不是改my.cnf全局值 - 注意
read_rnd_buffer_size是回表阶段用的，只有排序完成、还要根据ID捞整行时才触发；它和sort_buffer_size一样按连接独占，别一起拉高
tmp_table_size和max_heap_table_size设不对，会让GROUP BY直接写磁盘
复杂聚合查询（如带GROUP BY + COUNT(DISTINCT)）如果tmp_table_size太小，MySQL会在内存临时表撑满后转成磁盘MyISAM表，不仅慢，还会在/tmp或tmpdir里疯狂写文件，间接耗尽inode或磁盘空间，触发OOM Killer连带杀进程。
实操建议：
- 这两个值必须设成相等，否则以较小者为准；建议64M~256M之间，具体看平均聚合结果集大小
- 监控
SHOW STATUS LIKE 'Created_tmp_disk_tables'，如果该值持续增长，且Created_tmp_tables也高，说明内存临时表频繁溢出 - 不要盲目调大——更大的内存临时表意味着单次查询更吃内存；先用
EXPLAIN看是否能避免Using temporary，比如加索引或拆分子查询 -
tmpdir路径要有足够空间和权限，否则dump失败会导致查询中断，日志里会出现Can't create/write to file而非直接OOM
max_connections配错会让所有缓冲区乘法爆炸
MySQL内存公式里最隐蔽的炸弹是：per-thread buffers × max_connections。比如sort_buffer_size=4M、join_buffer_size=4M、read_buffer_size=2M，三个加起来10M，看着不大——但如果max_connections=1000，这部分就固定吃掉10GB，还没算buffer pool。
实操建议：
- 查当前最大连接数：
SHOW GLOBAL STATUS LIKE 'Max_used_connections'，按这个值上浮20%设max_connections，而不是拍脑袋写1000 - 应用层务必用连接池（如HikariCP、Druid），限制实际并发连接数，比MySQL端限流更早、更准
- 对长连接场景，定期执行
KILL闲置连接，或设wait_timeout和interactive_timeout为300~600秒 - 检查是否有未关闭的连接泄露：
SHOW PROCESSLIST里大量Sleep状态且Time值极大，就是典型信号
真正卡住人的地方，从来不是某个参数该设多少，而是多个参数叠加后的乘积效应——buffer pool占大头，per-connection buffer靠数量堆，tmp_table_size靠单次查询撑，三者一碰就超限。每次调参前，先算一遍理论峰值内存： innodb_buffer_pool_size + key_buffer_size + ((sort_buffer_size + join_buffer_size + read_buffer_size) × max_connections) + tmp_table_size，确保≤可用内存的80%。
