mysql如何排查Out of memory错误_mysql内存分配调优

应先用 ps 或 pmap 查 mysqld 进程 RSS 内存，而非仅调大 innodb_buffer_pool_size；RSS 超物理内存 80% 或远超配置参数总和时，需排查连接泄漏、临时表滥用、performance_schema 开销等隐性内存消耗。查 mysqld 进程实际内存占用，别只看 SHOW VARIABLESMySQL 报 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 就可能吃掉 4GBtmp_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 免费一键快速抠图，支持下载高清图片