MySQL 内存占用高，先看 innodb_buffer_pool_size
是否过大
这是最常见也最容易被误配的内存项。InnoDB 缓冲池默认可能占物理内存的 75%（尤其在 Docker 或云主机上自动调优后），但若你的实例只跑几个小表，或并发查询极少，这个值就是浪费——它会常驻内存，且不轻易释放。
查当前值：SHOW VARIABLES LIKE 'innodb_buffer_pool_size';合理范围：一般设为物理内存的 50%～70%，但必须结合实际数据量。比如总数据文件（
ibdata1+
*.ibd）才 2GB，却配了 16GB 缓冲池，基本就是冗余 动态调整（8.0+ 支持在线 resize）：
SET GLOBAL innodb_buffer_pool_size = 4294967296; -- 4GB，但需确保
innodb_buffer_pool_instances能整除新大小（如设为 4GB，建议
instances≥ 4）
连接数暴增导致 thread_stack
和 sort_buffer_size
累积耗尽内存
每个连接都会分配独立的线程栈和临时排序/join缓冲区。当
max_connections设得过高（如 1000+），而应用又没及时断开空闲连接，大量 sleeping 连接就会把内存悄悄吃光。 查活跃连接：
SHOW PROCESSLIST;，重点关注
Command为
Sleep且
Time> 300 的连接 限制单连接资源：
SET SESSION sort_buffer_size = 262144; -- 256KB，而非默认 2MB，配合应用层使用连接池（如 HikariCP）控制最大活跃数 缩短空闲超时：
SET GLOBAL wait_timeout = 60; SET GLOBAL interactive_timeout = 60;，避免连接“挂着不走”
tmp_table_size
和 max_heap_table_size
不匹配引发磁盘临时表误判
MySQL 用内存临时表加速 GROUP BY、ORDER BY 等操作，但这两个参数必须相等，否则即使内存充足，也会因
max_heap_table_size更小而强制落盘——落盘本身不耗内存，但后续磁盘 I/O 堵塞会导致连接堆积，间接推高内存占用。 检查是否一致：
SHOW VARIABLES LIKE 'tmp_table_size';<br>SHOW VARIABLES LIKE 'max_heap_table_size';统一设为合理值（如 64MB）：
SET GLOBAL tmp_table_size = 67108864;<br>SET GLOBAL max_heap_table_size = 67108864;验证效果：执行大结果集排序后，查
Created_tmp_disk_tables是否明显下降（
SHOW STATUS LIKE 'Created_tmp%';）
排查隐藏内存大户：查询缓存（Query Cache）已废弃但残留配置
MySQL 8.0 已彻底移除 query cache，但如果你是从 5.7 升级上来，且配置文件里还留着
query_cache_type = 1和
query_cache_size = 268435456，MySQL 会静默忽略这些参数——可问题在于，某些旧版监控脚本或 DBA 习惯性盯着
Qcache_状态变量，反而掩盖了真正的问题源。 确认是否启用（5.7 及以下）：
SHOW VARIABLES LIKE 'query_cache_%';，若
query_cache_size> 0，且业务无大量重复只读查询，建议关掉：
SET GLOBAL query_cache_type = 0;8.0+ 用户请直接删掉配置文件中的所有
query_cache_*行，避免干扰理解 真正该盯的是
Innodb_buffer_pool_read_requests与
Innodb_buffer_pool_reads比值，低于 99% 才说明缓冲池不够用，而不是盲目加内存
内存问题很少是单一参数惹的祸，往往是缓冲池配大了 + 连接池没管住 + 临时表阈值没对齐，三者叠加才让
top里的
mysqldRSS 居高不下。动手前务必先
SHOW ENGINE INNODB STATUS\G看 buffer pool 和 transaction section 的实时水位，比看配置文件更准。
