MySQL内存溢出本质是系统OOM-killer主动杀掉mysqld进程，需从系统日志（dmesg、/var/log/messages）、MySQL配置（innodb_buffer_pool_size、sort_buffer_size等连接级缓冲叠加效应）及performance_schema实时内存分布三线并查。
MySQL 内存溢出（OOM）本质是系统内存被耗尽后，Linux 的 oom-killer 主动杀掉 mysqld 进程——不是 MySQL 自己崩溃，而是被“处决”。排查必须从系统层、MySQL 配置层、运行时内存使用三线并进，单看日志或只调 innodb_buffer_pool_size 很可能白忙。
查系统日志确认是否真被 oom-killer 杀掉
这是第一道门槛。很多运维看到 MySQL 挂了就直接调参数，但根本没确认是不是 OOM 导致的。
- 执行
dmesg -T | grep -i "killed process"，若输出含mysqld和Out of memory，就是 oom-killer 下的手 - 检查
/var/log/messages或/var/log/syslog，搜索oom_kill或badness字样 - 注意时间戳对齐：MySQL 崩溃时间 vs dmesg 中 kill 时间必须一致，否则可能是其他原因（如磁盘满、信号中断）
- 如果没找到 oom-killer 记录，别硬往内存上扯——可能只是连接超时、主从 IO 线程异常或配置语法错误
看 MySQL 配置里哪些参数会“叠buff”式吃内存
innodb_buffer_pool_size 是大头，但它不是唯一凶手。多个连接级缓冲叠加后，总内存 = 连接数 × 单连接缓冲 + 全局缓冲，极易失控。
-
innodb_buffer_pool_size：专用库可设为物理内存 50%–80%，但必须预留至少 2GB 给 OS；混合部署（如共存 Nginx、Python 脚本）要先减去其他进程常驻内存再算 -
sort_buffer_size、join_buffer_size、read_buffer_size：每个连接独占，不是全局共享。设成 4M 且有 500 个活跃连接，光这三项就吃掉 6GB -
tmp_table_size和max_heap_table_size：控制内存临时表上限，两者取小值。设太大（如 512M）+ 复杂 GROUP BY 查询多 → 单查询就占几百 MB -
performance_schema：默认开启，高并发下自身内存开销可达 1–2GB；若不依赖其深度诊断，可设performance_schema=OFF（需重启）
用 performance_schema 查实时内存分布和碎片迹象
光看配置是静态的，真正要命的是运行中内存怎么分、有没有卡住不释放。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查各模块内存占用：
SELECT SUBSTRING_INDEX(event_name,'/',2) AS code_area, SUM(CURRENT_NUMBER_OF_BYTES_USED) AS used FROM performance_schema.memory_summary_global_by_event_name GROUP BY code_area ORDER BY used DESC;—— 关注innodb、sql、memory/heap三块是否异常偏高 - 查缓冲池碎片化：运行
SHOW ENGINE INNODB STATUS\G，在BUFFER POOL AND MEMORY段里找Free buffers和Database pages。若 Free buffers 长期 > 1000 但缓存命中率 - 查临时表落地磁盘：
SHOW STATUS LIKE 'Created_tmp%';若Created_tmp_disk_tables/Created_tmp_tables> 0.2，说明tmp_table_size不够，频繁触发磁盘临时表，间接加重 I/O 和内存调度压力
调 innodb_buffer_pool_size 时最容易踩的三个坑
这个参数看似简单，但动态调整或跨版本迁移时，细节决定成败。
- 动态修改（
SET GLOBAL innodb_buffer_pool_size = ...）要求新值必须是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍，否则报错ER_INVALID_VALUE_FOR_VAR - 调大后不配
innodb_buffer_pool_instances：当缓冲池 > 1GB，建议按每 1GB 分 1 个 instance（如 12GB → 设为 12），否则所有线程争同一把 mutex，CPU sys% 暴涨，反而拖慢 - 云环境虚机要注意：某些厂商的“弹性内存”虚拟机，
/proc/meminfo显示的 MemTotal 会随负载浮动，用它算 70% 可能某天突然超限；应以云控台标注的“固定内存规格”为准
真正难的不是知道该调哪个参数，而是得同时盯住三件事：系统是否正在杀进程、MySQL 当前内存怎么花的、那些“每个连接都来一口”的缓冲有没有被低估。一不留神，把 innodb_buffer_pool_size 从 16G 调到 24G，结果 sort_buffer_size 还卡在 8M、连接池峰值冲到 800，总内存照样爆表。
