Buffer Pool设置过大易触发OOM，建议设为物理内存50%–70%；连接数暴增、临时表/排序内存滥用及插件内存泄漏也会导致内存吃满，需结合监控与SQL优化综合治理。
Buffer Pool设置过大导致内存吃满
MySQL的innodb_buffer_pool_size不是“越大越好”，尤其在物理内存有限、又跑着其他服务（比如Redis、Nginx）的机器上，设成80%内存常直接触发OOM Killer杀掉mysqld进程。
实操建议：
- 线上环境建议设为物理内存的50%–70%，且不超过
innodb_buffer_pool_size上限（MySQL 5.7+支持动态调整，但需注意分块数innodb_buffer_pool_instances要匹配，否则实际生效值可能被截断） - 检查是否启用了
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup——它们会把热数据页序列化到磁盘（默认路径ib_buffer_pool），重启时加载。若热数据集远小于Buffer Pool总大小，加载过程反而拖慢启动，还占用额外I/O和内存缓存 - 用
SHOW ENGINE INNODB STATUS\G查Buffer pool hit rate，长期低于95%说明Buffer Pool没被有效利用，可能SQL没走索引或存在大量全表扫描，光调大参数没用
连接数暴增却不释放，堆满内存
每个MySQL连接默认分配线程栈（thread_stack，通常192KB–2MB）、临时表内存（tmp_table_size/max_heap_table_size）、排序缓冲区（sort_buffer_size）等。连接数从100飙到1000，光线程栈就可能多占1GB+内存。
常见错误现象：
-
SHOW PROCESSLIST里一堆Sleep状态连接，Time列持续增长，但应用层没主动close() - 监控显示
Threads_connected长期高于max_connections设定值（说明已拒绝新连，但旧连接卡住） - 错误日志出现
Too many connections，但SHOW VARIABLES LIKE 'max_connections'明明设得够大
实操建议：
- 确认应用是否用完连接不归还：PHP的
mysql_connect()未配persistent却复用资源；Java里HikariCP的connection-timeout和idle-timeout设得太长，或没开启leak-detection-threshold - 调低数据库侧保活阈值：
wait_timeout和interactive_timeout建议设为60–300秒（非交互式连接默认8小时，极易堆积） - 避免在事务里长时间sleep或做耗时计算——
START TRANSACTION; SELECT ...; SLEEP(60); COMMIT;会让连接锁住资源一整分钟
临时表和排序操作偷偷吃光内存
当查询需要排序、去重、关联或GROUP BY，且数据量超过sort_buffer_size或tmp_table_size时，MySQL会把临时结果写入磁盘（Created_tmp_disk_tables计数上升），但这之前仍会先尝试在内存里建临时表，这部分内存不会被Buffer Pool统计，容易被忽略。
实操建议：
- 监控状态变量：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';，若Created_tmp_disk_tables / Created_tmp_tables > 0.1，说明内存临时表经常撑爆，需调高tmp_table_size和max_heap_table_size（二者必须相等才生效） - 不要全局盲目调大
sort_buffer_size：它是**每个连接独占**的，1000个连接×2MB = 2GB白占内存。优先优化SQL（加索引避免filesort）或改用更小的值（如256K） - 用
EXPLAIN FORMAT=JSON看执行计划里的using_temporary和using_filesort字段，定位具体哪条SQL在滥用临时资源
内存泄漏型插件或UDF引发缓慢增长
极少数情况下，第三方存储引擎（如TokuDB旧版）、自定义UDF（用户函数）、或MySQL自身bug（如某些5.7.28前版本在长期运行+大量DDL后Performance Schema内存不释放），会导致RSS内存持续上涨，但SHOW ENGINE INNODB STATUS看不出异常。
实操建议：
- 用
ps aux --sort=-%mem | head -20确认mysqld进程RSS是否真涨，再对比cat /proc/$(pidof mysqld)/status | grep VmRSS，排除系统缓存误判 - 临时关闭
performance_schema（设performance_schema=OFF并重启），观察几天内存趋势——它在高并发下本身就有内存开销，且某些版本存在释放延迟 - 检查是否启用了
query_cache_type=1：Query Cache在高写入场景下锁争用严重，且碎片化后内存难以回收，MySQL 8.0已移除，5.7建议设为0
Buffer Pool和连接管理是可控的，但临时表行为和底层模块的内存释放逻辑，往往藏在慢查询和配置组合的缝隙里——盯着SHOW GLOBAL STATUS里几个关键比率，比死盯总内存数字有用得多。
