VPS知识分享站先说结论：2 核 4G 能跑小站和轻量业务，但 MySQL 的 buffer pool 只能给 1 到 1.5G；4 核 8G 适合中型站点和并发不高的 API；8 核 16G 起才谈得上“数据库专用机”。比起 CPU，MySQL 更吃内存和磁盘 IOPS。
选配置前先算三笔账：数据量、并发连接、峰值 QPS。数据量决定 buffer pool，连接数决定内存上限，QPS 决定 CPU 和磁盘。
内存怎么分
MySQL 内存大头是 InnoDB buffer pool，通常给物理内存的 50% 到 70%。剩下的留给连接、排序、临时表、系统和其他进程。
- 2G 内存：buffer pool 512M 到 1G，只适合小库
- 4G 内存：buffer pool 1G 到 2G，小站够用
- 8G 内存：buffer pool 4G 到 5G，中型业务
- 16G 以上：按数据热区给，别把整机内存吃满
# my.cnf 示例（4G 内存）
innodb_buffer_pool_size = 1536M
max_connections = 100
innodb_log_file_size = 256M
slow_query_log = 1
long_query_time = 0.5
CPU 和连接数
MySQL 单条查询主要吃单核，复杂聚合和并发才会吃多核。2 核适合低并发，4 核是常见起点，8 核以上要配合连接池和慢查询治理。
max_connections 不是越大越好。每个连接都占内存，连接数打满后新请求会排队。应用侧用连接池，数据库侧按内存算上限。
磁盘比 CPU 更重要
数据库最怕随机 IO 慢。选本地 SSD 或高 IOPS 云盘，别用网络存储跑热库；binlog、redo log、数据文件分开或至少保证足够空间。磁盘满了，MySQL 可能直接停写。
配置对照表
| 场景 | 配置 | 说明 |
|---|---|---|
| 个人站、小工具 | 2 核 4G，80G SSD | buffer pool 1G 左右，日PV 几千 |
| 中型站点、API | 4 核 8G，160G SSD | buffer pool 4G，连接池 100 以内 |
| 高并发、订单库 | 8 核 16G 起 | 独立数据盘、主从、监控齐全 |
| 分析/报表 | 另开从库 | 别在主库跑大查询 |
参数和慢查询
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW STATUS LIKE 'Threads_connected';
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS;先开慢查询日志，把超过 0.5 秒的 SQL 捞出来，补索引、拆查询、避免 N+1。大多数“数据库慢”不是配置问题，是 SQL 和索引问题。
备份怎么做
- 逻辑备份：
mysqldump，适合小库和迁移 - 物理备份：XtraBackup，适合大库和快速恢复
- binlog：按时间点恢复，必须开
- 备份放站外，定期做恢复演练
mysqldump --single-transaction --routines --triggers \
-u root -p appdb > /backup/appdb-$(date +%F).sql
常见坑
- buffer pool 设太大，系统 OOM
- max_connections 设太高，内存被连接吃光
- 没开慢查询，问题全靠猜
- 数据盘和系统盘共用，日志写满系统盘
- 只备份数据不备份 binlog，恢复不到时间点
- 主库跑报表，业务被拖慢
连接池和并发
应用侧连接池不是越大越好。连接数超过数据库能处理的并发，只会增加上下文切换和锁等待。按“数据库核数 × 2 到 4”估算，再压测确认；连接池空闲回收也要开，避免占着连接不干活。
主从和读写分离
读多写少的业务可以加从库，把报表、列表、搜索放从库，主库只处理写入和强一致读。注意主从延迟：刚写完立刻读从库可能读不到，关键链路要强制走主库或做延迟判断。
监控指标
至少盯这几个：连接数、QPS、慢查询数、InnoDB 缓冲池命中率、磁盘使用率、主从延迟。缓冲池命中率长期低于 95%，说明内存不够或查询太散；磁盘使用率超过 80% 就要清理或扩容。
云数据库和自建怎么选
云数据库省运维，自动备份、主从、监控都现成，但价格高、参数受限；自建灵活、便宜，但要自己负责备份、升级和故障。小团队优先云数据库，有 DBA 或成本敏感再自建。
什么时候该分库分表
单表几千万行、查询开始明显变慢时，先做索引优化、归档历史数据、读写分离；这些都不够再考虑分库分表。分库分表会带来跨库查询、事务和运维复杂度，别为了“看起来专业”提前上。
还有一条经验：数据库机器不要兼职跑应用、备份和爬虫，资源争抢时最先出问题的是 IO。
如果业务还在增长，配置至少留 30% 余量，别等磁盘和连接数都贴着上限才扩容。
数据库的监控告警要接到人，不要只发邮件到没人看的邮箱。
配置是起点，持续观察和调整才是日常。
建议每月复盘一次，按实际负载调整配置，别让默认值一直跑下去。
常见问题 FAQ
Q1：2 核 4G 能跑 MySQL 吗？
能跑小站和轻量业务，buffer pool 给 1G 左右，连接数控制在 100 以内。数据量大或并发高就上 4 核 8G。
Q2：MySQL 需要独立服务器吗？
数据量大、并发高、合规要求高时建议独立。小站和应用同机可以，但要给数据库留足内存和磁盘。
Q3：CPU 高还是 IO 高？
看慢查询和 iostat。复杂查询吃 CPU，随机读多、buffer pool 不够吃 IO。
Q4：云数据库和自建怎么选？
不想运维、要自动备份和主从，选云数据库；要可控成本、自定义参数，自建更灵活。
Q5：要不要上主从？
读多写少、需要容灾和备份窗口时上主从；单机也能跑，但故障恢复时间长。
总结
MySQL 选配置，先看数据量和连接数，再给 buffer pool 留够内存，最后选高 IOPS 磁盘。2 核 4G 能起步，4 核 8G 更稳，8 核 16G 以上再谈专用。慢查询和备份，比堆配置更重要。
需要一台独立数据库机器做测试或从库，可以按小时开一台萤光云香港 CN2 VPS，先跑一轮真实数据。
