MySQL内存异常需综合排查：先用SHOW ENGINE INNODB STATUS和sys.memory_by_host_by_current_bytes定位真实占用，再查慢查询、临时表及配置参数合理性，排除系统干扰与旧版本Bug。
MySQL内存占用异常，通常不是单一配置导致，而是多个参数协同作用或业务负载突变引发。关键要区分是正常缓存增长，还是内存泄漏、配置失当或查询失控所致。
检查当前内存实际使用情况
仅看top或ps显示的RSS值容易误判——MySQL大量使用缓冲池（InnoDB Buffer Pool）、查询缓存、排序区等，这些内存由MySQL自身管理，不等于进程常驻内存持续上涨。先运行以下命令确认真实压力点：
- SHOW ENGINE INNODB STATUS\G：重点关注BUFFER POOL AND MEMORY段，看Buffer pool size是否接近配置值，以及Free buffers是否长期为0
- SHOW VARIABLES LIKE '%buffer%'; SHOW VARIABLES LIKE '%cache%';：核对innodb_buffer_pool_size、key_buffer_size、tmp_table_size、max_heap_table_size等关键参数是否远超物理内存
- SELECT * FROM sys.memory_by_host_by_current_bytes;（需启用performance_schema）：定位哪个主机/IP或用户占用了最多内存
排查低效大查询和临时表膨胀
很多“内存飙升”实际源于单条SQL触发大量内存临时表或排序。重点查：
- 开启慢查询日志并设置long_query_time = 1，配合log_queries_not_using_indexes = ON，捕获未走索引的全表扫描语句
- 监控Created_tmp_disk_tables和Created_tmp_tables状态变量：若前者占比高（如>20%），说明tmp_table_size或max_heap_table_size设得太小，频繁落地磁盘；若总量激增，大概率有GROUP BY、ORDER BY无索引的大结果集
- 用EXPLAIN FORMAT=JSON分析可疑SQL，关注using_temporary和using_filesort字段
验证配置参数是否合理
常见错误配置会直接导致内存超限：
- innodb_buffer_pool_size设为物理内存80%以上，又同时开启大key_buffer_size（MyISAM）或query_cache_size（已弃用但旧配置仍存在）
- sort_buffer_size、join_buffer_size、read_buffer_size等线程级参数设得过大（如>4M），在并发连接数高时呈倍数放大
- 未限制max_connections，导致大量空闲连接持续占用线程内存（每个连接至少几百KB）
建议：缓冲池保留70–75%物理内存；线程级缓冲保持默认（256K–2M），除非有明确优化依据；用wait_timeout和interactive_timeout及时回收空闲连接。
排除非MySQL进程干扰与版本Bug
某些场景下，内存问题并非MySQL本身引起：
- 检查是否有其他服务（如Redis、Java应用）在同一机器争抢内存，导致系统OOM Killer杀掉mysqld
- 查看MySQL错误日志中是否出现Out of memory、cannot allocate memory或signal 9等字样
- 确认MySQL版本：5.7.20+ 和 8.0.12+ 修复了多个Buffer Pool内存释放延迟、InnoDB字典缓存泄漏等问题；老旧版本（如5.6.x）存在已知内存缓慢增长Bug
