必须先确认mysql是否被oom-killer杀死，而非自身崩溃；查dmesg或系统日志中“killed process”及时间戳匹配，再分析连接级缓冲叠加、pfs统计盲区与global_connection_memory_tracking等机制。
MySQL 8.0 进程被系统 OOM-killer 杀掉，不是 MySQL 自己崩溃，而是 Linux 主动“处决”——必须先确认这点，否则所有调参都是白忙。
怎么看是不是真被 oom-killer 杀的
别只盯着 MySQL 错误日志。OOM 是系统层行为，证据在内核日志里：
- 运行
dmesg -T | grep -i "killed process"，输出含mysqld和Out of memory才算实锤 - 查
/var/log/messages或/var/log/syslog，搜oom_kill或badness字样 - 比对时间戳：MySQL 崩溃时间必须和 dmesg 中 kill 时间一致；不一致就不是 OOM，可能是磁盘满、配置语法错或信号中断
- 如果没找到任何 oom-killer 记录，立刻停手——别再调
innodb_buffer_pool_size，那解决不了问题
为什么 top 里 mysqld RSS 高但 performance_schema 统计不到那么多
performance_schema.memory_summary_global_by_event_name 只统计它能 hook 到的内存路径，大量内存不在其覆盖范围内：
-
innodb_buffer_pool_size是常驻内存，但它的分配走的是 mmap，PFS 默认不追踪（除非开启memory/innodb/buffer_poolinstrument） - Group Replication 的
memory/group_rpl/Gcs_xcom::xcom_cache、JIT 解析器、jemalloc 内部碎片、复制线程缓存等，都不计入 PFS 总和 - 执行
SELECT SUM(CAST(REPLACE(current_alloc,'MiB','') AS DECIMAL(10,2))) FROM sys.memory_global_by_current_bytes WHERE current_alloc LIKE '%MiB%'，若结果远低于top显示的 RSS（比如 2GB vs 56GB），说明大量内存由非 PFS 路径分配 - 此时不能只信 PFS 数据，得结合系统级指标看真实压力
哪些参数叠加起来会“悄无声息吃光内存”
真正要命的不是单个大参数，而是连接级缓冲 × 并发数的指数级叠加：
-
sort_buffer_size、join_buffer_size、read_buffer_size：每个连接独占，不是共享。设成 4M，有 300 个活跃连接，光这三项就吃掉 3.6GB -
tmp_table_size和max_heap_table_size：取小值，控制内存临时表上限。设 512M + 高频 GROUP BY → 单查询可能占几百 MB，多个并发直接爆掉 -
max_connections设 2000，但实际峰值仅 80？那 1920 个空闲连接仍会预分配thread_stack（默认 256KB）和基础缓冲，隐性浪费超 480MB -
performance_schema：默认开启，高并发下自身开销可达 1–2GB；若不用深度诊断，可设performance_schema=OFF（需重启）
MySQL 8.0.28+ 有个新工具但容易被忽略
global_connection_memory_tracking 是少数能抓到“垃圾 SQL 吃内存”过程的机制，但它默认关闭且不追踪 buffer pool：
- 先开开关：
SET GLOBAL global_connection_memory_tracking = ON - 查总量：
SHOW GLOBAL STATUS LIKE 'Global_connection_memory'—— 这个值不含 innodb buffer pool - 设限制：
SET GLOBAL connection_memory_limit = 4194304（4MB），再用普通用户执行可疑 SQL；超限会报ERROR 4082 (HY000): Connection closed. Connection memory limit 4194304 bytes exceeded，并告诉你实际消耗多少字节 - 注意：
connection_memory_limit对 root 或有SUPER权限的用户无效；必须用业务账号测试才准
buffer pool 是常驻的，其他连接级缓冲是“按需分配、连接结束释放”的，但释放不及时或连接堆积就会卡住；排查时永远先看系统日志确认是否真 OOM，再看配置叠加效应，最后才信 PFS 的细分数据——三者缺一不可。
