答案：MySQL内存溢出需从配置、运行状态和外部调用排查。先检查innodb_buffer_pool_size等关键参数是否合理，避免连接级缓冲过大；再通过performance_schema分析内存使用，查看临时表创建情况和慢查询，定位高耗资源SQL；最后结合系统日志确认是否被OOM kill，并监控整体内存趋势。合理配置缓冲区、控制连接数、优化低效SQL是解决核心。
MySQL 出现内存溢出（Out of Memory, OOM）通常表现为服务崩溃、被系统 kill，或监控中看到内存使用持续增长。排查这类问题需要从配置、运行状态和外部调用三个层面入手。以下是具体排查方法。
检查 MySQL 配置项
MySQL 的多个参数直接影响内存使用，配置不当容易导致内存超限：
- innodb_buffer_pool_size：这是最大头的内存占用者，通常建议设置为物理内存的 50%~70%。如果设置过高，在高并发下可能与其他内存叠加导致溢出。
- key_buffer_size：MyISAM 表索引缓存，若未使用 MyISAM，可调小至 8M~16M。
- query_cache_size：查询缓存，MySQL 8.0 已移除。如使用老版本且开启，建议关闭（设为 0），因其在高并发下易引发锁争用和内存碎片。
- tmp_table_size 和 max_heap_table_size：控制内存临时表大小，过大会导致单个查询占用过多内存。
- sort_buffer_size、join_buffer_size、read_buffer_size 等连接级缓冲：这些是每个连接独占的，连接数多时总内存 = 连接数 × 缓冲大小，需谨慎设置，一般不建议超过 2M~4M。
可通过以下命令查看当前配置：
SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ( 'innodb_buffer_pool_size', 'key_buffer_size', 'tmp_table_size', 'max_heap_table_size', 'sort_buffer_size', 'join_buffer_size', 'read_buffer_size' );分析运行时内存使用情况
通过性能视图观察实际内存分配：
- 使用 performance_schema 查看各组件内存使用：
重点关注 innodb、sql、memory/heap 等模块。
- 检查是否有大量临时表写入磁盘：
若 Created_tmp_disk_tables 很高，说明内存临时表不足，可能频繁创建磁盘表，间接反映 tmp_table_size 设置不合理。
- 查看当前连接与线程内存消耗：
关注长时间运行、状态为 "Sending data"、"Copying to tmp table" 的查询，这些往往是内存大户。
检查慢查询与异常 SQL
内存溢出常由低效 SQL 引发，尤其是全表扫描、大结果集排序或 GROUP BY 操作。
- 启用慢查询日志，定位执行时间长或扫描行数多的语句：
结合 pt-query-digest 分析日志，找出消耗资源最多的 SQL。
- 对可疑 SQL 使用 EXPLAIN 分析执行计划，确认是否缺少索引、产生临时表或 filesort。
系统层排查与监控
MySQL 被系统 OOM kill 时，可检查系统日志：
dmesg | grep -i 'oom\|kill'若输出包含 out of memory: Kill process，说明系统内存不足，MySQL 是受害者。此时应：
- 检查服务器是否运行其他高内存程序。
- 限制 MySQL 总内存上限，留出系统余量。
- 考虑升级内存或优化应用连接池，避免连接数暴增。
部署监控工具（如 Prometheus + Grafana、Zabbix）持续观察 MySQL 内存趋势、连接数、缓冲池使用率等指标，有助于提前预警。
基本上就这些。关键是合理配置缓冲区，控制连接级别内存，再配合慢查询优化，大多数内存溢出问题都能解决。
