在 Linux 环境下遭遇 MySQL 内存溢出导致崩溃时，许多人的第一反应是调整 innodb_buffer_pool_size，但往往越调越糟。根据我观察的多个案例，问题根源并非 buffer pool，而是其他隐性内存消耗将系统推至临界点。正确的排查路径是：先确认是否被 oom-killer 杀掉，再逐步分析各个内存组件。
确认是否确实被 oom-killer 终止
遇到 MySQL 崩溃不要急于调参，先判断是否为系统级 OOM。执行 dmesg -T | grep -i "killed process" | grep mysqld，若输出内容的时间戳与 MySQL 崩溃时刻吻合，说明确实被 OOM 杀掉；否则可能是磁盘空间不足、网络中断或配置语法错误所致。
同时检查 /var/log/messages 或 /var/log/syslog，搜索 oom_kill 或 badness 关键词。若未发现此类记录，就不必盲目归因于内存问题。
不要只看 free -h 的 MemTotal，重点关注 MemAvailable
云服务器（例如阿里云共享型、AWS t3 实例）的 MemTotal 存在虚高现象，真正可分配给 MySQL 的硬上限是：cat /proc/meminfo | grep MemAvailable。从这个值中减去 2–4GB（用于操作系统、agent 和备份脚本），才是安全边界。
innodb_buffer_pool_size 必须 ≤ 这个安全边界，否则就是埋下隐患。在配置文件中设置为 2G 或 2048M 是可行的，但动态调整时必须使用字节单位（如 2147483648），且必须是 128MB（即 134217728 字节）的整数倍，否则会被静默截断或报错。
performance_schema 和触发器是隐形的内存消耗大户
开启 performance_schema 并启用 memory/% = COUNTED 后，memory/sql/sp_head::main_mem_root 在重放包含数十个触发器的 binlog 时，单次可能消耗数 GB 内存。这并非 buffer pool 的问题，而是 SQL 线程加载触发器上下文导致的额外开销。
实时查看内存占用：SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/sql/sp_head%' ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 1。如果该值排在前三且持续增长，基本可以确定是它导致的。
临时缓解措施：
- 关闭 performance_schema：
SET GLOBAL performance_schema = OFF（永久生效需重启实例） - 将
table_open_cache_instances从默认的 16 改为 1，减少每个 instance 缓存的 sp_head 实例数量 - 注释掉非必要的触发器，特别是那些包含
SELECT ... INTO @var或拼接长字符串逻辑的
连接级缓冲叠加起来相当惊人
sort_buffer_size、join_buffer_size、read_buffer_size 都是按“每个连接”分配的，并非全局共享。若每个设为 4MB，同时有 500 个活跃连接，仅这三项就会消耗 6GB 内存。
tmp_table_size 和 max_heap_table_size 取较小值，以控制内存临时表的上限。设得过大（如 512MB）且查询中频繁使用复杂 GROUP BY，单个查询就可能占用数百 MB 内存。
max_connections 必须严格控制，在宝塔面板环境下建议设为 50–100；低内存机器（≤2GB）不要强行给 buffer pool 分配 1.5G，同时清理已废弃的 query_cache_size 和残留的 key_buffer_size。
buffer pool 虽然占用最大，但真正致命的是 buffer pool 占满后，其他内存组件没有余量，共同将系统推过临界点。调参之前请先执行 ps aux --sort=-%mem | head -5，确认 mysqld 是否真的排第一——如果不是，先干掉那个吃内存的 Python 或 Java 进程。
