应检查innodb_buffer_pool_size是否远超可用内存，确保其≤available-2GB；tmp_table_size与max_heap_table_size必须相等；监控Created_tmp_disk_tables增长及Threads_connected，调低per-connection缓冲和wait_timeout；关闭非必要performance_schema监控或存储过程。
查 innodb_buffer_pool_size 是否远超可用内存
这个值是MySQL启动时就向OS硬申请的固定内存块，不随负载收缩。哪怕只执行一条 SELECT 1，它也占着——Linux的OOM Killer就爱杀这种“虚胖”进程。
执行 SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，再对比 free -h 输出里的 available 列（不是 free）；若服务器总内存64GB、available 常驻仅8GB，却配了48GB buffer pool，必须下调。
保守建议：设为 available - 2GB 以内；MySQL 8.0+支持在线调整，但新值需满足：innodb_buffer_pool_size % (innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances) == 0，否则会被向下取整——执行后务必再查一遍确认生效值。
盯紧 Created_tmp_disk_tables 和两个临时表参数是否一致
若 tmp_table_size=16M 而 max_heap_table_size=64M，MySQL会按更小的那个（16M）判定内存临时表上限，一超就落盘。磁盘临时表本身不耗内存，但后续I/O堵塞会让连接堆积，线程数飙升，间接推高 sort_buffer_size 等per-connection内存总量。
- 执行
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size';核对，必须完全相等 - 统一设为合理值，如
SET GLOBAL tmp_table_size = 67108864;+SET GLOBAL max_heap_table_size = 67108864;（64MB） - 持续观察
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，若该值每分钟增长 > 10，说明SQL没走索引或GROUP BY/ORDER BY触发了大量磁盘临时表
检查活跃连接数与 sort_buffer_size 类参数的实际放大效应
每个活跃连接都会独占 sort_buffer_size、join_buffer_size、thread_stack 等内存。设 sort_buffer_size=4M、max_connections=1000，光排序缓冲就可能吃掉4GB——哪怕99%连接处于Sleep状态。
执行 SHOW STATUS LIKE 'Threads_connected';，对比 max_connections；若长期 > 70% 且 SHOW PROCESSLIST 里大量 Sleep 且 Time > 300，说明应用层连接没复用或泄漏。
- 降低会话级缓冲：例如
SET SESSION sort_buffer_size = 262144;（256KB），比默认2MB更安全 - 缩短空闲超时：
SET GLOBAL wait_timeout = 60;，避免连接挂着 - 排查应用是否使用了
multiple statements（分号连发多条SQL）或超长BULK INSERT，这类操作在SQL解析阶段就会预分配大量内存，且延迟释放
别忽略 performance_schema 和存储过程类对象的隐性开销
MySQL 8.0+ 中，performance_schema 默认开启，其内存占用可高达几百MB甚至上GB（尤其当监控项全开时）。执行 SELECT event_name, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED) FROM performance_schema.memory_summary_global_by_event_name ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 5; 可快速定位大头。
存储过程、函数、触发器在MySQL中属于“非轻量级对象”，它们的执行上下文、变量栈、结果集缓存都常驻内存且释放不及时。特别是长期未调用但已加载的存储过程，可能持续占用几十MB。
- 检查业务库是否存在大量自定义存储过程：
SELECT Routine_schema, Routine_type FROM information_schema.Routines WHERE Routine_schema NOT IN ('mysql','information_schema','performance_schema','sys'); - 若确认非必要，建议停用并删除；若必须保留，可考虑关闭
performance_schema（设performance_schema=OFF）并重启，或至少禁用高频低价值监控项（如setup_instruments中的memory/%） -
sys.memory_global_by_current_bytes视图比SHOW VARIABLES更真实反映当前内存分布，优先用它交叉验证
实际排查时，最易被忽略的是：内存上涨未必是“泄露”，而是多个小参数在高并发下被同时放大；innodb_buffer_pool_size 是锚点，但真正让内存“卡住不放”的，往往是那些 per-connection 参数和未清理的存储过程上下文。
