应先用 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 延迟卡死。
更糟的是：当 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，而不是配置值。
