先划清这篇和《EXPLAIN结果看不懂？丢给AI要索引优化建议，人工确认再落地》的边界。《EXPLAIN结果看不懂？丢给AI要索引优化建议，人工确认再落地》讲的是用 EXPLAIN 分析单条 SQL、配合 AI 给出索引建议，解决的是“某条查询为什么慢”。这篇管的是另一个层面：MySQL 服务本身作为一台刚上线的小内存服务器（1-2G 内存 的 VPS 是大多数个人站长的常态），默认参数明显偏向“谁都别惹事”，实际上把性能压制了。参数调优不必一上来就研究几百个变量，起步阶段就四个点：缓冲池给足、日志文件合理、连接数对齐、慢查询日志打开。
最重要的一个参数是 innodb_buffer_pool_size。InnoDB 把数据和索引都缓存在这里，查询能不能不走磁盘全看它。MySQL 默认只给 128M——这对一台 2G 内存的机器来说太抠了。专用数据库服务器的经验值是物理内存的 50%-70%，考虑到我们的 VPS 上还跑着 Nginx、PHP-FPM，给系统留足空间，1G 内存的机器给 256M-384M，2G 内存给 512M-768M，往上按这个比例推。
第二是连接数 max_connections。MySQL 默认 151，《MySQL 1040 Too many connections：连接泄漏定位与上限设定》写过它被打满会报 1040 错误。调连接数前先想清楚一件事：每个连接都是要吃内存的，连接数和 PHP-FPM 的进程数应该匹配——PHP-FPM 总共 10 个 worker，理论上同时最多也就 10 个数据库连接，把 max_connections 拉到 500 毫无意义，反而放大风险。小站给它 100-200 就绰绰有余，真正的瓶颈通常不在这。
第三是慢查询日志。这不是性能参数，是你的诊断工具——不先把日志打开，后面所有优化都是盲人摸象。log_queries_not_using_indexes 这个选项争议较大（会把很多正常查询也记进来，日志容易膨胀），起步阶段只记执行时间超阈值的查询就够用。
编辑 /etc/mysql/conf.d/tuning.cnf（没有就新建，保持主配置文件干净）：
[mysqld]
# 缓冲池：按机器内存取，2G内存机器给到768M
innodb_buffer_pool_size = 768M
# redo log 文件大小，写入频繁的站点调大可减少checkpoint
# MySQL 8.0.30+ 用这个变量（旧版本是 innodb_log_file_size）
innodb_redo_log_capacity = 256M
# 连接数：和PHP-FPM的pm.max_children*每请求连接数对齐
max_connections = 150
# 超时回收空闲连接，防连接泄漏占坑
wait_timeout = 300
# 慢查询日志：起步阶段必开
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
# 临时表尽量走内存，避免磁盘临时表
tmp_table_size = 64M
max_heap_table_size = 64M
重启 MySQL 让配置生效，然后逐项验证。缓冲池是最关键的，验证它有没有真的被用起来，看状态变量里的命中率：
sudo systemctl restart mysql
# 进MySQL查缓冲池状态
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"
# Innodb_buffer_pool_reads = 从磁盘读了多少次
# Innodb_buffer_pool_read_requests = 从内存读了多少次
# 命中率 = 1 - (reads / read_requests)
# 跑几天后应该稳定在99%以上
# 命中率低于95%，说明buffer_pool给小了，加大它
MySQL 8.0 还有个好用的特性 SET PERSIST，可以不改配置文件在线改参数并自动持久化，重启后依然生效，适合临时调参验证：
-- 在线调整并持久化（写进mysqld-auto.cnf）
SET PERSIST max_connections = 150;
-- 恢复默认
SET PERSIST max_connections = DEFAULT;
慢查询日志开了之后，别只让它在磁盘上躺着。跑一两天，用《MySQL 慢查询拖垮 CPU：processlist 到 pt-query-digest》讲过的 pt-query-digest 分析一遍：
pt-query-digest /var/log/mysql/slow.log > slow_report.txt
# 看报告头部的TOP榜单：哪些查询占了总时间的70%
# 对排名前几的查询，回到《EXPLAIN结果看不懂？丢给AI要索引优化建议，人工确认再落地》的EXPLAIN流程逐条分析
最后给个心态上的建议：参数调优的边际收益递减非常快。buffer_pool 给足、慢查询日志开着，这两件事做完，一个日均几万 PV 的站点八成瓶颈已经不在这儿了，剩下的时间应该花在索引和查询本身。看到网上流传的“百条 my.cnf 优化模板”不要照抄，那些参数大多是为高并发大库准备的，小站抄过来除了占内存没别的用。参数没有标准答案，buffer_pool 命中率、慢查询条数这两个指标才是你判断配置好坏的依据。
相关阅读：数据库四参数是加固清单的必勾项。《性能与安全加固总清单：按这张表打勾，新站48小时达到生产水准》的性能组五篇各管一层，本篇管数据层，打完勾性能基线就有了。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
