MySQL内存优化核心是合理分配缓冲区，重点调优innodb_buffer_pool_size（设为物理内存50%–75%，支持在线调整）、连接级buffer（如sort_buffer_size≤2MB，防OOM）、tmp_table_size等，并监控命中率、磁盘临时表比率及系统swap，持续验证。
MySQL内存使用优化核心在于合理分配关键缓冲区，避免内存浪费或频繁换页。重点调优innodb_buffer_pool_size、key_buffer_size（仅MyISAM）、sort_buffer_size等参数，同时结合实际负载动态调整，而非盲目堆大内存。
优先调优InnoDB缓冲池
InnoDB表占主流时，innodb_buffer_pool_size是最大内存消耗项，应设为物理内存的50%–75%，但需预留足够内存给OS和其他进程。例如16GB服务器可设为10GB：
注意：该参数在MySQL 5.7+支持在线动态调整（需整数倍于innodb_buffer_pool_chunk_size），重启非必需。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 监控命中率：查询
SHOW STATUS LIKE 'Innodb_buffer_pool_read%'，计算(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100，理想值＞99% - 若命中率低且buffer pool已较大，应检查SQL是否缺少索引，而非继续加内存
- 启用
innodb_buffer_pool_instances（建议设为CPU核心数，≤64）可减少争用，提升并发性能
控制连接级内存分配
每个客户端连接会独占sort_buffer_size、join_buffer_size、read_buffer_size等内存，设置过大易导致OOM（尤其高并发场景）。
- 默认值（如256KB）通常够用，勿轻易调至几MB；线上建议
sort_buffer_size≤ 2MB，join_buffer_size≤ 4MB - 这些参数是**每个连接独享**，1000个连接 × 4MB = 4GB，务必按峰值连接数估算总开销
- 可通过
SHOW PROCESSLIST观察长时间运行的排序/连接操作，针对性优化SQL，比调大buffer更有效
精简全局缓存与临时表设置
全局性缓存如query_cache_size（MySQL 8.0已移除）和tmp_table_size/max_heap_table_size影响内存稳定性。
- MySQL 5.7及以前：若QPS高但查询重复率低，建议关闭查询缓存：
query_cache_type=0，避免锁争用 -
tmp_table_size和max_heap_table_size必须相等，控制内存临时表上限（如64MB）。超过则自动转磁盘临时表，慢但保稳定 - 通过
Created_tmp_disk_tables / Created_tmp_tables比率判断是否过小，＞10%说明频繁落盘，可适度上调
定期验证与持续监控
调优不是一劳永逸。上线后需用工具跟踪真实内存行为：
- 用
SHOW ENGINE INNODB STATUS\G查看buffer pool使用详情和等待事件 - 配合
performance_schema查内存分配：如SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE event_name LIKE 'memory%'; - 观察系统层面：Linux下
free -h和cat /proc/meminfo | grep -i "swap\|commit"确认是否发生swap或过度commit
