mysql如何排查Out of memory错误 mysql内存分配调优最佳实践|Duuu笔记
应先用 ps 或 pmap 查 mysqld 进程 RSS 内存，而非仅调大 innodb_buffer_pool_size；RSS 超物理内存 80% 或远超配置参数总和时，需排查连接泄漏、临时表滥用、performance_schema 开销等隐性内存消耗。
查
mysqld
进程实际内存占用，别只看
SHOW VARIABLES
MySQL 报
Out of memory
时，很多人第一反应是调大
innodb_buffer_pool_size
，结果反而更早崩。真实内存消耗不只来自这个参数——
mysqld
进程的 RSS 内存可能远超所有“可配置内存参数”之和。
真正该先做的，是用系统命令看进程实占：
ps -o pid,rss,vsz,comm -C mysqld
或
pmap -x $(pgrep mysqld)
。RSS 超过物理内存 80% 就危险；若 RSS 比
innodb_buffer_pool_size + key_buffer_size + sort_buffer_size * max_connections
大出一倍以上，说明有隐性内存泄漏或连接数失控。
每个连接独占
sort_buffer_size
、
read_buffer_size
、
join_buffer_size
等线程级缓冲区，
max_connections = 1000
且
sort_buffer_size = 4M
就可能吃掉 4GB
tmp_table_size
和
max_heap_table_size
控制内存临时表上限，但没设限的查询（如没加
LIMIT
的
GROUP BY
）会把整张中间结果塞进内存
开启
performance_schema
后，尤其在高并发下，其内部结构本身会吃掉几百 MB，且无法通过 SQL 关停
定位触发 OOM 的具体查询：从
slow_query_log
到
performance_schema
不是所有慢查询都吃内存，但吃内存的查询往往很慢，而且
Rows_examined
极高。关键要区分：是单条大查询撑爆内存，还是大量小查询累积耗尽。
打开
slow_query_log
并设
log_queries_not_using_indexes = ON
，同时重点看
long_query_time = 0
（记录所有查询），再配合
pt-query-digest
分析
Rows_examined
和
Tmp_tables
字段。如果某类查询频繁出现
Using temporary; Using filesort
且
Rows_examined > 1e6
，基本就是内存黑洞。
启用
performance_schema
后，查
performance_schema.memory_summary_by_thread_by_event_name
可看到各线程内存分配峰值，注意
EVENT_NAME LIKE '%memory%'
的行
information_schema.PROCESSLIST
中
State
为
Creating tmp table
或
Copying to tmp table
的连接，正在用内存建临时表
避免在
WHERE
或
JOIN
条件中对字段用函数（如
DATE(create_time)
），这会让索引失效，强制全表扫描+内存排序
innodb_buffer_pool_size
不是越大越好，Linux 的
vm.swappiness
会暗中捣鬼
设
innodb_buffer_pool_size = 70% RAM
是常见建议，但在容器环境或混部机器上极易翻车。InnoDB 缓冲池是 mmap 分配的匿名内存，Linux 内核不会优先把它换出，而其他进程（比如 Python 应用）的堆内存却容易被
swappiness
换出，导致 MySQL 看似“空闲”却因系统级 swap 延迟卡死。
自由画布
百度文库和百度网盘联合开发的AI创作工具类智能体
下载
更糟的是：当
innodb_buffer_pool_size
接近物理内存，而又有大量连接创建内存临时表，内核 OOM Killer 可能直接杀掉
mysqld
进程，并在
dmesg
里留下
Killed process mysqld (pid 12345)
—— 这不是 MySQL 自己报错，根本不会写进 error log。
生产环境建议：缓冲池设为物理内存的 50%~60%，留足空间给 OS cache、连接缓冲、其他服务
确认
vm.swappiness = 1
（不是 0！0 会禁用 swap，反而让 OOM Killer 更激进）
用
cat /proc/$(pgrep mysqld)/status | grep -E '^(VmRSS|VmSize)'
对比 RSS 和 VmSize，若 VmSize 远大于 RSS，说明有大量 mmap 区域未实际驻留，但已计入虚拟内存限额
检查
max_connections
和连接生命周期，长连接比慢查询更隐蔽地耗内存
一个空闲的 MySQL 连接仍占用至少 256KB 内存（线程栈 + 各 buffer），如果应用层用了连接池但没设
max_idle_time
，或客户端异常断连后连接没及时释放，连接数会缓慢爬升，最终在半夜流量低谷时因内存碎片化触发 OOM。
查当前连接状态：
SHOW STATUS LIKE 'Threads_connected'
，再对比
max_connections
。若长期 >70% 且
Threads_created
持续增长，说明连接复用率低；若
Threads_connected
稳定在高位但
Queries
很低，大概率是连接泄漏。
应用侧必须设连接空闲超时（如 JDBC 的
maxLifetime
、
idleTimeout
），数据库侧配
wait_timeout
和
interactive_timeout
（建议 300 秒以内）
避免在事务里长时间 sleep 或等待外部 API，事务开启期间所有分配的内存都不会释放
监控
Aborted_connects
和
Aborted_clients
：前者多说明认证失败洪水攻击，后者多说明客户端非正常断连，都会残留半开连接
内存问题最麻烦的从来不是参数数字，而是多个小配置叠加后产生的非线性挤压——比如
sort_buffer_size
看似才 2MB，但乘上 300 个连接，就是 600MB 隐形开销，再叠加上
tmp_table_size
和未释放的连接，就刚好卡在临界点上。盯住 RSS，而不是配置值。
