为什么 MySQL 内存参数值得调

很多个人站长的 MySQL 配置还是安装时默认生成的，512MB 的小内存机器却开着为 16GB 内存设计的参数，或者反过来：明明机器有 4GB 内存，innodb_buffer_pool_size 却只有默认的 128MB，InnoDB 缓冲池命中率低得可怜，同样的查询每次都要读磁盘。MySQL 的内存参数直接决定了两件事：数据缓存在内存里的比例，以及并发连接下内存会不会被打爆。这篇文章从测量开始，逐个讲清楚 InnoDB 缓冲池、连接、排序临时表、日志相关的核心参数，最后给出一份可以直接抄的配置模板。

一、调优前先测量

不测量就调参等于瞎猜。先登录 MySQL 看当前配置和运行状态：

mysql -u root -p
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';

重点关注两个指标：缓冲池命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests，命中率长期低于 99% 说明缓冲池偏小；Threads_connected 与 max_connections 的比值，如果经常超过 80%，说明连接数快不够了。另外用 free -m 看物理内存总量，这是所有内存参数的天花板。

二、核心参数：innodb_buffer_pool_size

经验值是物理内存的 50% 到 70%，但必须减去其他进程的占用：一台跑着 Nginx、PHP-FPM 和 MySQL 的 2GB 机器，留给 MySQL 的缓冲池建议 768MB 到 1GB，而不是直接 1.4GB，否则 PHP-FPM 高峰期内存不足会触发 OOM Killer 把 MySQL 干掉。怎么确认缓冲池真的用上了这么多内存？可以查 information_schema 的内存统计视图，或者看系统侧：MySQL 进程的 RSS 占用会明显上升，但注意 RSS 里还包含线程栈、网络缓冲等其他内存，不要用它精确反推缓冲池大小。最直观的验证方式还是看命中率指标，命中率上去说明缓冲池确实在发挥作用，内存没有白给。

[mysqld]
innodb_buffer_pool_size = 1G

MySQL 8.0 支持在线调整，不需要重启就能改，改完观察效果再固化到配置文件：

SET GLOBAL innodb_buffer_pool_size = 1073741824;

注意这个参数设置的是字节数。调整后再次查看命中率，如果还是不到 99%，而内存还有富余，可以继续加大。

三、缓冲池实例与预热

缓冲池超过 1GB 时建议拆成多个实例，减少内部锁竞争：innodb_buffer_pool_instances 默认在缓冲池大于 1GB 时自动设为 8，一般不用手动改。还有一个容易被忽略的参数是 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，开启后 MySQL 关闭时把缓冲池中的热数据页位置记录下来，重启后自动加载，避免重启后的一段时间命中率暴跌：

[mysqld]
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

四、连接相关参数

max_connections 决定最大并发连接数。个人站默认 151 通常够用，但如果你发现 Threads_connected 经常打满，先别急着盲目调大，因为每个连接都要占用内存，连接数翻倍内存消耗也跟着翻倍。更健康的做法是检查应用侧是否有连接泄漏：PHP-FPM 的 mysqlnd 连接池是否配置合理、是否有脚本忘了释放连接。

[mysqld]
max_connections = 200
thread_cache_size = 32
wait_timeout = 60
interactive_timeout = 300

thread_cache_size 缓存线程避免频繁创建销毁，wait_timeout 控制空闲连接多久被断开，调小一点可以防止大量闲置连接占满上限。back_log 是连接排队数，默认值即可，不要调太大，排队过长说明连接数真的不够了。日常可以用 mysqladmin 快速查看连接状况：mysqladmin -u root -p status 输出里的 Threads 就是当前连接数，mysqladmin processlist 能看到每个连接正在执行的语句。排查连接泄漏时 processlist 特别好用，如果发现大量 Sleep 状态的连接越积越多，说明应用侧没有正确释放连接，这时候应该先修代码，而不是急着调大 max_connections。

五、排序与临时表：警惕 per-connection 陷阱

sort_buffer_size、join_buffer_size、read_buffer_size 这三个参数是每个连接各自分配一份的，不是全局共享。很多教程让人无脑调大，结果 200 个连接乘 16MB 排序缓冲区就是 3.2GB，小内存机器直接 OOM。个人站保持默认或小幅调优即可：

[mysqld]
sort_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 32M
max_heap_table_size = 32M

tmp_table_size 和 max_heap_table_size 决定内存临时表的上限，超过就会落到磁盘临时表，性能骤降。可以用 SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables' 观察，如果磁盘临时表数量异常多，优先优化 SQL 本身，而不是继续加内存，因为很多磁盘临时表是 GROUP BY、ORDER BY 缺少索引导致的。

六、日志与刷盘策略

redo log 太小会导致频繁刷盘，太大则崩溃恢复时间长。MySQL 8.0.30 之前用 innodb_log_file_size 控制，8.0.30 之后改用 innodb_redo_log_capacity，默认 100MB，对写入量大的站建议调到 256MB 或 512MB：

[mysqld]
innodb_redo_log_capacity = 268435456

innodb_flush_log_at_trx_commit 决定事务提交时 redo log 的刷盘方式：默认 1 每次提交都刷盘，最安全但最慢；设为 2 每秒刷一次，崩溃时最多丢一秒数据；设为 0 完全交给系统。个人网站可以权衡：对数据敏感的操作保持 1，普通场景用 2 能显著提升写入性能，但要做好最多丢 1 秒数据的心理准备。

七、查询缓存：已废弃的功能

老教程里经常出现的 query_cache_type 和 query_cache_size 在 MySQL 8.0 里已经被彻底移除，配置了会直接报错。查询缓存当年的设计在高并发写入下反而成为全局锁瓶颈，现在缓存层的正解是应用层 Redis 或 MySQL 8.0 的 InnoDB 缓冲池本身。如果你在网上看到调优文章还让你开 query_cache，直接跳过，那篇文章大概率过时了。

八、2GB 内存 VPS 配置模板

综合以上，一份适合 2GB 内存、跑着 Nginx + PHP-FPM + MySQL 的个人站的配置模板：

[mysqld]
innodb_buffer_pool_size = 768M
innodb_buffer_pool_instances = 8
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON
innodb_redo_log_capacity = 268435456
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 150
thread_cache_size = 32
wait_timeout = 60
interactive_timeout = 300
sort_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 32M
max_heap_table_size = 32M
performance_schema = OFF

innodb_flush_method 设为 O_DIRECT 让 InnoDB 绕过系统页缓存直接读写磁盘，避免数据页在 InnoDB 缓冲池和系统缓存里各存一份造成内存浪费。performance_schema 在不需要诊断性能问题时可以关掉，它本身会占用约几百 MB 内存，对小机器是实打实的节省。改完用 mysql 客户端执行 SHOW VARIABLES 确认全部生效，再观察几天状态值。

九、验证与监控

调优后要验证效果，不能改完就完事。用 SHOW ENGINE INNODB STATUS 查看缓冲池命中率和 redo log 使用情况；把 Threads_connected、Innodb_buffer_pool_reads 这些状态量接入监控脚本，每天记录一次，趋势异常时能及时发现。最重要的监控是内存本身：用 free -m 和系统日志盯住 OOM Killer 的记录，一旦 MySQL 被 kill 过，说明内存参数仍然偏激进，要立即回调。

十、大页内存与版本差异

Linux 默认使用 4KB 大小的内存页，InnoDB 缓冲池动辄几百 MB 到几 GB，会产生大量页表项。大页内存（HugePages，通常 2MB 一页）能减少 TLB miss，理论上对数据库性能有帮助，但配置不当反而会出问题：hugepages 数量预留不足时 MySQL 直接无法分配内存启动失败，而且 MySQL 8.0 默认并不使用大页分配缓冲池。个人站长不建议折腾 HugePages，除非是纯数据库专用机器且确实遇到内存带宽瓶颈。版本差异方面要特别注意：5.7 用 innodb_log_file_size 控制 redo log，8.0.30 之后改成了 innodb_redo_log_capacity，按老教程配置会启动失败；8.0 移除了 query_cache，相关的状态变量也一并消失。升级版本前用 MySQL Shell 的 upgrade checker 检查配置兼容性，比启动报错后再排查省事得多。查看缓冲池运行细节可以用 information_schema.INNODB_BUFFER_POOL_STATS 表，比 SHOW STATUS 更全面，直接能看到缓冲池大小、数据页数量和命中统计。

十一、常见误区

最后总结几个高频误区：第一，所有 per-connection 参数（sort_buffer_size 等）不能按全局思维调大；第二，缓冲池不是越大越好，要留足操作系统和其他服务的内存；第三，命中率低不一定是缓冲池小，也可能是查询没走索引，全表扫描把缓冲池污染了；第四，参数调优替代不了索引优化，一个合适的索引带来的提升比几百 MB 缓冲池大得多。内存调优是锦上添花，SQL 和索引才是根子上的性能。

结语

MySQL 内存调优的完整思路是：先测量当前状态，再围绕缓冲池、连接、临时表、日志四条线逐个调整，每改一个参数都观察一段时间，最后把验证和监控固化到日常运维里。个人站的流量规模下，把 innodb_buffer_pool_size 调到合理值、关掉 performance_schema、控制好 per-connection 参数，通常就能解决 80% 的内存和性能问题。剩下的精力，请留给索引和慢查询。