一、装数据库之前先算账:你的数据量需要多大内存

绝大多数人在 VPS 装数据库时犯的第一个错误,是先装再想配置。装完发现数据库起不来,或者跑起来半小时就被 OOM Killer 杀掉,根因往往在开头就已经决定。
InnoDB 的工作集模型给了一条实用的估算线:内存至少要是"数据量 × 1.3"的 2 倍。所谓工作集,就是数据库真正频繁读写的那部分数据,它通常等于数据文件本身再加上索引,因为索引是存在数据表空间里的。按这个公式倒推:数据集 5GB,工作集约 6.5GB,内存需要 13GB;数据集 20GB,工作集约 26GB,内存需要 52GB;数据集 50GB,工作集约 65GB,内存需要 130GB;数据集 200GB,工作集约 260GB,内存需要 520GB。
这套算法里 1.3 这个系数是给索引和临时排序留的余量,不是拍脑袋的数。你可以在自己的库上验证:SELECT SUM(data_length+index_length) FROM information_schema.TABLES WHERE table_schema='你的库名'; 出来的就是数据加索引的真实占用,比翻目录看文件大小准。
单位成本怎么算才算明白?三个口径:折合月价除以内存容量得出每 GB 内存成本,除以磁盘容量得出每 GB 磁盘成本,除以月流量得出每 TB 流量成本。折合月价本身要先归一——按年计费的机型把年付价除以 12,按月计费的直接用月价。下面是来自真实商品库的单位成本对比表。
| 机型 | 折合月价 | 内存 | 每 GB 内存成本 |
|---|---|---|---|
| RosCloud-06 | 69.99 美元 | 24GB | 2.92 美元 |
| RosCloud-04 | 49.99 美元 | 8GB | 6.25 美元 |
| RosCloud-03 | 39.99 美元 | 4GB | 10.00 美元 |
| RosCloud-01 | 19.99 美元 | 1GB | 19.99 美元 |
| LAX-LARGE | 133.33 美元 | 16GB | 8.33 美元 |
| LAX-MICRO | 33.33 美元 | 4GB | 8.33 美元 |
| IRVINE-PRO-MICRO | 45.83 美元 | 4GB | 11.46 美元 |
| Residential-LARGE | 138.33 美元 | 16GB | 8.65 美元 |
| 云途 HK.DS.S | 800 元 | 128GB | 6.25 美元 |
| 云途 DS.ES.B | 1500 元 | 256GB | 5.86 美元 |
| 云途 DS.ES.A | 800 元 | 32GB | 25.00 美元 |
这里已经出现一个反常识的事实:同一家厂商内部,低端型号的单位成本可能比高端型号高出一倍多。RosCloud-01 的每 GB 内存成本是 19.99 美元,RosCloud-06 只要 2.92 美元,差了将近 7 倍。这不是厂商在坑人,而是规模效应——配置越低,固定成本摊到每 GB 内存上的比例越高。反过来,云途的 DS.ES.A 和 HK.DS.M 都是 32GB 内存,前者每 GB 要 25.00 美元、后者只要 10.94 美元,同一家内部两台机器的差距也能到两倍多。
把内存成本再折算成"每 1GB 可用缓冲池的月成本"更有决策价值,因为 InnoDB 只能用掉约 65% 的物理内存做缓冲池,剩下的要留给连接、排序缓冲和操作系统:
| 机型 | 内存 | 可用缓冲池 | 每 GB 缓冲池月成本 |
|---|---|---|---|
| RosCloud-06 | 24GB | 15.60GB | 4.49 |
| RosCloud-04 | 8GB | 5.20GB | 9.61 |
| RosCloud-03 | 4GB | 2.60GB | 15.38 |
| RosCloud-01 | 1GB | 0.65GB | 30.75 |
| LAX-LARGE | 16GB | 10.40GB | 12.82 |
| LAX-Storage-500G | 4GB | 2.60GB | 12.82 |
| 云途 HK.DS.S | 128GB | 83.20GB | 9.62 |
| 云途 DS.ES.B | 256GB | 166.40GB | 9.01 |
这张表就是决策依据:如果你的数据库要吃内存,先算单位内存成本,再决定买哪一档。用 1GB 内存跑数据库不是不行,是单位成本最亏的选择——同样的钱买 RosCloud-03(39.99 美元)能拿到 4GB 内存和 2.60GB 缓冲池,是 RosCloud-01 的四倍容量。
补一句容易被忽略的:内存单价低的机型未必适合你。RosCloud-06 的内存单价全表最低,但它的带宽是 500Mbps、月流量 6144GB;如果你的应用层要传输大文件,这个 500Mbps 的上限会先成为瓶颈。单位成本只是账的一半,另一半是这项配置能不能承接你的实际负载。
真正的落地做法是拿三个数去和你的现状对表:数据量用 information_schema.TABLES 查,内存用 free -m 看现有机器的峰值,流量用云服务商控制台的月度出网账单看。三者对齐之后,再回到上面两张表里选行。
二、系统初始化:不装宝塔也能干净利落地完成部署

数据库装在什么系统上,直接影响后面三年的维护成本。选 Ubuntu Server 22.04 或 24.04 LTS 这类长期支持版本,把基础环境做干净,比事后补锅省事。
第一步是更新系统与设置时区:
sudo apt update && sudo apt upgrade -y
sudo timedatectl set-timezone Asia/Shanghai
第二步是加一个非 root 的管理账号。数据库服务不该用 root 身份跑,这是最容易被忽略也最容易被扫描器利用的入口:
sudo adduser --disabled-password --gecos "" deploy
sudo usermod -aG sudo deploy
第三步是配置 SSH 密钥登录并关闭密码登录。密码爆破是 VPS 被入侵的第一大来源:
sudo mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "你的公钥" >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
sudo sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh
第四步是装防火墙,只放行必要端口。3306 绝对不要对公网开放:
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
sudo ufw enable
第五步是加 swap。内存不足时 MySQL 8.0 不会像 5.7 那样直接报错退出,而是依赖 swap 续命,然后在随机时刻被 OOM Killer 干掉——这是最难排查的一类故障。给 2GB 内存的机器配 4GB swap 是底线:
sudo fallocate -l 4G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
第五步的常见报错是 swapon: /swapfile: swapon failed: Invalid argument,原因通常是文件系统是 btrfs 或分区太小,换成 ext4 文件或改用分区即可。
第六步是装运维基础工具。没有它们,出问题时你只能靠猜:
sudo apt install -y net-tools htop iotop unzip curl git vim tmux
第七步是设置自动安全更新。这条命令会让系统自动打补丁,但生产环境建议改成手动打,避免重启打断服务:
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
第八步是校准时间。数据库的 binlog 复制、慢日志时间戳、证书有效期全依赖系统时钟,时钟不准会让排查彻底失去参照:
timedatectl status
sudo timedatectl set-ntp true
这一步做完后基础环境才算合格。判断标准很简单:新机器上执行 ss -lntp,除了 22 端口不应该有其他监听;执行 free -m,swap 已生效;执行 curl -s ifconfig.me 能拿到公网 IP 且和面板显示的一致——最后这一条能提前发现 NAT 或端口映射的问题。
三、内存与内核参数调优:让数据库吃满配额

装完系统只是开始,真正的性能分水岭在 /etc/mysql/mysql.conf.d/mysqld.cnf 里。最要紧的三组参数:
第一组是 InnoDB 缓冲池。按物理内存的 60%–70% 设置,把剩下的留给连接、排序缓冲和操作系统。你可以用一条命令算出应该填多少:
MEM=$(free -g | awk '/Mem:/ {print $2}')
POOL=$(awk -v m="$MEM" 'BEGIN {printf "%.0f", m*0.65}')
echo "innodb_buffer_pool_size = ${POOL}G"
以 8GB 内存的机型为例,缓冲池应该是 5.20GB。RosCloud-04 是 8GB 内存(49.99 美元/月),LAX-MICRO 也是 8GB(33.33 美元/月,4 核),云途 HK.DS.P 是 64GB(750 元/月),HK.DS.S 是 128GB(800 元/月)——云途这两款留给缓冲池的空间分别是 41.60GB 和 83.20GB。
第二组是连接数。默认值往往开得过大,导致每个连接都占一份内存:
max_connections = 200
max_connect_errors = 10000
第三组是文件描述符与临时表。默认 tmp_table_size 只有 16MB,稍大的 GROUP BY 就会把中间结果写到磁盘:
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1
tmp_table_size = 256M
max_heap_table_size = 256M
改完重启并确认参数真的生效:
sudo systemctl restart mysql
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size');"
如果 SHOW VARIABLES 出来的值和配置文件里写的不一样,十有八九是读错了配置文件路径(Debian 系是 /etc/mysql/mysql.conf.d/mysqld.cnf,RHEL 系是 /etc/my.cnf.d/),或者有另一个配置文件在后面覆盖了它。用 mysqld --verbose --help | grep my.cnf 能看到实际读取的顺序。
还有一类性能问题出在文件系统而不是 MySQL 本身。把数据目录放在 ext4 上和放在 XFS 上,大并发写入时的表现有明显差别;启用 O_DIRECT 与 noatime 挂载选项也能减少不必要的写入放大:
sudo systemctl stop mysql
sudo mount -o remount,noatime,nodiratime /var/lib/mysql
对 MySQL 8.0 来说,innodb_redo_log_capacity 是很多人忽略的参数。默认值往往按老版本设定,改为动态扩容后,写入高峰时性能更平滑:
innodb_redo_log_capacity = 1073741824
innodb_log_buffer_size = 64M
innodb_flush_method = O_DIRECT
同理,innodb_io_capacity 和 innodb_io_capacity_max 要按你的存储介质来设。SSD 建议 2000/4000,HDD 建议 200/400。设置错误的表现是 CPU 很低但磁盘利用率 100%,队列全堵在 I/O 上。
最后一步是确认缓冲池真的按预期生效:
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A 3 "Buffer pool"
输出里的 "Buffer pool size" 应当和配置文件里的数值一致。差得远说明参数被覆盖了,或者内存分配失败后自动降级了。
四、安装 MySQL 8 与初始账号配置

Ubuntu 22.04 官方源里的 MySQL 已经是 8.0,直接装即可:
sudo apt install -y mysql-server
sudo systemctl enable --now mysql
初始化时用 mysqld --initialize-insecure 会让 root 没有密码,这在自动化脚本里方便,但必须在第一次启动后立刻改掉。推荐用 --initialize 走安全初始化流程,让它把随机密码写到日志里。
装好之后立刻做三件事:改 root 密码、删掉默认的匿名用户和 test 库、创建只监听本地或内网的绑定地址。
sudo mysql_secure_installation
手工核查匿名用户和空密码用户是否已经清干净:
SELECT user, host, plugin FROM mysql.user WHERE user='' OR (plugin='' OR plugin='mysql_native_password' AND authentication_string='');
如果查询有结果,说明还有空密码账号,必须清掉。
数据库只对本机或内网开放,靠绑定地址控制,而不是靠防火墙端口规则:
[mysqld]
bind-address = 127.0.0.1
需要远程管理的话,更安全的做法是走 SSH 隧道,而不是开 3306:
ssh -L 13306:127.0.0.1:3306 user@你的VPS
mysql -h 127.0.0.1 -P 13306 -u deploy -p
应用侧的连接账号要用最小权限原则。下面这套命令建一个只能读写指定库、不能建库不能改权限的账号:
CREATE DATABASE IF NOT EXISTS app CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'127.0.0.1' IDENTIFIED BY '强密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON app.* TO 'appuser'@'127.0.0.1';
FLUSH PRIVILEGES;
常见报错:创建用户时报 ERROR 1396 (HY000): Operation CREATE USER failed for 'appuser'@'localhost',说明该用户已存在,直接用 ALTER USER 改密码;报 ERROR 1044 (42000): Access denied for user 说明当前账号权限不够,要用 root 登录执行。
建完账号还要验证权限确实生效,而不是只看命令返回成功:
mysql -h 127.0.0.1 -u appuser -p app -e "SHOW GRANTS;"
输出里应当只有 GRANT SELECT, INSERT, UPDATE, DELETE ON app.* TO 'appuser'@'127.0.0.1' 这一类授权语句。如果出现了 ALL PRIVILEGES 或者 SUPER,说明授权给错了账号,这等于把整台机器交出去了。
再测一次越权是否被拦住:
mysql -h 127.0.0.1 -u appuser -p -e "CREATE DATABASE hack;"
正确行为是返回 ERROR 1044 (42000): Access denied for user 'appuser'@'localhost'。如果居然建库成功了,说明账号权限过大,必须收回重授。
最后是字符集。中文站点的数据库不配 utf8mb4 会出现 emoji 存不进去、生僻字变成问号这类问题,必须在建库时指定:
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
正确的组合是 utf8mb4 搭配 utf8mb4_0900_ai_ci(MySQL 8.0 默认)或 utf8mb4_unicode_ci。连接时客户端也要带上:
mysql --default-character-set=utf8mb4 -h 127.0.0.1 -u deploy -p
如果 character_set_database 显示的是 latin1,说明建库时没指定 charset,需要 ALTER DATABASE app CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 修正。
五、备份与恢复:数据库的保险丝

不备份的数据库等同于没有数据库。在 VPS 上做备份要处理两个维度:本地快照(防误删、防磁盘损坏)和异地副本(防机房级事故)。
逻辑备份用 mysqldump,单库备份:
mysqldump --single-transaction --quick --routines --triggers --events \
-u deploy -p app | gzip > /backup/app_$(date +%F).sql.gz
--single-transaction 是 InnoDB 的一致性快照,不锁表;--quick 逐行读取,避免大表撑爆内存;--routines --triggers --events 把存储过程、触发器和事件一起带上——只导表结构的那种备份在恢复时最容易出事。
恢复演练必须做,不能只验证备份文件存在:
zcat /backup/app_2026-11-04.sql.gz | mysql -u deploy -p test_restore
mysql -u deploy -p -e "SELECT COUNT(*) FROM test_restore.users;"
物理备份适合数据量大、恢复时间要求高的场景:
sudo systemctl stop mysql
sudo tar -czf /backup/mysql_data_$(date +%F).tar.gz /var/lib/mysql
sudo systemctl start mysql
备份文件本身也要备份。放在同一块盘上的备份在磁盘坏掉时一起消失,等于没备份。可以用 cron 每天同步到另一台机器或对象存储:
0 3 * * * rsync -az --delete /backup/ backup@另一台机器:/data/mysql_backup/
一个容易被忽略的坑:磁盘配额和备份空间是共用同一块盘时,备份任务会把根分区写满,导致 MySQL 无法写入、整个服务停摆。给备份目录挂独立卷,或者至少在脚本里加一句 df -h / | awk 'NR==2 {if ($5+0 > 85) exit 1}' 做空间检查。
备份保留策略也要定下来,否则磁盘会被旧备份吃光。用一条命令只保留最近 7 天的逻辑备份:
find /backup -name "app_*.sql.gz" -mtime +7 -delete
binlog 也要限制保留量。MySQL 8.0 默认的 binlog 过期时间是 30 天,如果每分钟写几个事务,binlog 目录很快就能吃掉几十 GB:
SET GLOBAL binlog_expire_logs_seconds = 604800;
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);
数据库层面的备份还要和慢日志、错误日志一起管。慢日志不清理会无限增长,通常设成保留 7 天:
slow_query_log_file = /var/log/mysql/slow.log
log_expire_logs_days = 7
最后是加密。备份文件里往往包含用户密码哈希、手机号、身份证等敏感数据,直接放在磁盘上或者同步到对象存储,一旦泄露就是事故。用 GPG 加密后再传:
gpg --symmetric --cipher-algo AES256 backup_$(date +%F).sql.gz
有一类事故只有靠备份能救:误删表。DROP TABLE 在 MySQL 里是 DDL,进了 binlog,可以用 mysqlbinlog 按时间点恢复:
mysqlbinlog --start-datetime="2026-11-04 10:00:00" --stop-datetime="2026-11-04 10:05:00" /var/lib/mysql/binlog.000042 | mysql -u root
前提是 binlog_format 设置成了 ROW,并且 binlog 还在保留期内。所以 binlog 的保留期必须大于你发现误删所需的最长时间。
六、验收阈值:这几项达标才算装成功

装完不等于能用。下面是四个可以照着执行的数字阈值,达不到就说明环境有问题,继续往下做只会放大问题。
连接建立时间 < 100ms。本地回环连接应当是毫秒级:
time mysql -h 127.0.0.1 -u deploy -p app -e "SELECT 1;"
1MB 数据查询响应 < 200ms。用一个真实表做冷查询测试:
time mysql -h 127.0.0.1 -u deploy -p app -e "SELECT * FROM big_table LIMIT 1000;"
内存谷值 < 15%。装完数据库静置十分钟后看内存占用:
free -m
健康的空闲 MySQL 应该在 8GB 内存机器上占用不到 1.2GB。超过 15% 说明配置过激或连接数设置过大。
磁盘可用空间 > 40%。数据库运行期需要空间做临时文件、binlog 和在线 DDL:
df -h /var/lib/mysql
慢查询必须被记录。开慢日志是排查性能问题的前提:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
改完重启后,用 tail -f /var/log/mysql/slow.log 盯着看。任何超过 1 秒的查询都应该被当作待优化项。
备份文件必须可读。最后一条阈值:gunzip -t /backup/app_*.sql.gz 返回 0 才算备份有效。这一步很多人在真正需要恢复时才第一次做,代价极高。
主从复制延迟 < 1 秒。如果你的架构有只读副本,这项必须达标:
SHOW SLAVE STATUS\G
看 Seconds_Behind_Master 这一列。超过 1 秒说明主库写入压力过大或者网络延迟高,读请求分配策略要调整。
数据库连接建立后 TIME_WAIT 数量 < 100。连接数泄漏的早期信号:
ss -ant | grep TIME-WAIT | wc -l
慢查询占比 < 0.1%。用这个语句看整体情况:
SHOW GLOBAL STATUS LIKE 'Slow_queries';
对比 SHOW GLOBAL STATUS LIKE 'Questions'; 的比值,超过千分之一就说明索引需要优化了。
七、流量与带宽怎么算:数据库只占小头,大头在应用

很多人以为数据库最吃流量,其实不是。数据库的流量主要是查询结果集,通常很小;真正吃流量的是应用层返回的图片、JS/CSS 和接口数据。
按每个页面访问平均消耗 0.5MB 流量估算,各机型的承载能力差异非常明显。下表折算的是每百万次页面访问摊到的月成本,流量越大、单价越低的机型越划算:
| 机型 | 折合月价 | 月流量 | 日均访问量 | 每百万次访问成本 |
|---|---|---|---|---|
| LAX-STARTER | 16.67 美元 | 5000GB | 34.1 万次 | 1.63 |
| LAX-MICRO | 33.33 美元 | 10000GB | 68.3 万次 | 1.63 |
| LAX-MEDIUM | 66.67 美元 | 20000GB | 136.5 万次 | 1.63 |
| LAX-LARGE | 133.33 美元 | 40000GB | 273.1 万次 | 1.63 |
| LAX-Storage-1TB | 58.33 美元 | 15000GB | 102.4 万次 | 1.90 |
| Residential-STARTER | 21.67 美元 | 5000GB | 34.1 万次 | 2.12 |
| Residential-MICRO | 38.33 美元 | 10000GB | 68.3 万次 | 1.87 |
| IRVINE-PRO-STARTER | 29.17 美元 | 5000GB | 34.1 万次 | 2.85 |
| IRVINE-PRO-MICRO | 45.83 美元 | 10000GB | 68.3 万次 | 2.24 |
| RosCloud-01 | 19.99 美元 | 1024GB | 7.0 万次 | 9.53 |
| RosCloud-02 | 29.99 美元 | 2048GB | 14.0 万次 | 7.15 |
| RosCloud-03 | 39.99 美元 | 3072GB | 21.0 万次 | 6.36 |
| RosCloud-04 | 49.99 美元 | 4096GB | 28.0 万次 | 5.96 |
| RosCloud-05 | 59.99 美元 | 5120GB | 35.0 万次 | 5.72 |
| RosCloud-06 | 69.99 美元 | 6144GB | 41.9 万次 | 5.56 |
sixtynet 的 LAX 系列在这一项上优势明显,而且大档位没有规模折扣——LAX-STARTER 与 LAX-LARGE 的每百万次访问成本完全相同,因为带宽和流量配额是同步放大的,从 2000Mbps/5000GB 一路到 10000Mbps/40000GB,成本曲线是线性的。相比之下 RosCloud 系列流量配额小但单价也低,折算下来每百万次访问成本落在 5.56 到 9.53 之间。
云途系列因为是按月付人民币计价,流量单价明显更高:HK.DS.M 月付 350 元、流量 10000GB,每百万次访问成本约 17.09 元;DS.ES.C 月付 700 元、流量 40000GB,每百万次约 8.54 元;HK.DS.S 月付 800 元、流量 40000GB,每百万次约 9.77 元;DS.ES.B 月付 1500 元、流量 30000GB,每百万次约 24.41 元,是全表最高的一档。
磁盘单位成本的差距更大,这一列是存储型需求的第一决策依据:
| 机型 | 磁盘 | 折合月价 | 每 GB 磁盘成本 |
|---|---|---|---|
| LAX-Storage-1TB | 1000GB | 58.33 美元 | 0.058 |
| LAX-Storage-500G | 500GB | 33.33 美元 | 0.067 |
| 云途 HK.DS.S | 6000GB | 800 元 | 0.133 |
| 云途 DS.ES.F | 800GB | 399 元 | 0.499 |
| 云途 HK.DS.B | 2000GB | 1200 元 | 0.600 |
| RosCloud-06 | 320GB | 69.99 美元 | 0.219 |
| RosCloud-04 | 160GB | 49.99 美元 | 0.312 |
| RosCloud-03 | 80GB | 39.99 美元 | 0.500 |
| RosCloud-02 | 40GB | 29.99 美元 | 0.750 |
| RosCloud-01 | 20GB | 19.99 美元 | 0.999 |
要做数据库,选存储型机型的性价比远高于选同内存的通用型。LAX-Storage-1TB 用 8GB 内存换 1000GB 磁盘,磁盘单价 0.058 美元/GB,是全表最低,但它的内存单价 7.29 美元/GB 并不便宜——它适合"数据大、并发低"的场景,比如日志库、备份库、数据仓库;如果你的负载是高并发小查询,内存才是瓶颈,应该看 LAX-LARGE 这类 16GB 内存、320GB 盘的机型,它每 GB 磁盘成本 0.417 美元,虽然贵,但内存供给是 8GB 存储型机型的两倍。
流量成本和磁盘成本的组合决策才是完整答案。举三个具体例子:日志留存一年、总量 2TB 每天写入,看磁盘单价选 LAX-Storage-1TB;论坛每天 10 万次访问,看流量和内存选 LAX-MEDIUM;后台管理系统只有 200 个并发用户但要存 500GB 历史订单,看内存加磁盘的平衡点选 LAX-LARGE 加对象存储分层。
有一件事必须提前讲清楚:数据库本身产生的流量很小。一次返回 100 条记录的查询,出网流量可能只有几十 KB。真正吃流量的是应用层返回的图片、静态资源和接口数据。所以如果你发现流量费超支,问题通常出在应用层没做缓存,而不是数据库配置错了。
八、什么情况下不该选小配置(以及替代方案)

这一节讲的是反向决策。判断依据只取公开事实——机房位置、线路类型、计费方式、IP 资源,不涉及任何商家的服务质量评价。
场景一:数据集超过 40GB 且有并发写入。 按第一节的公式,40GB 数据需要约 104GB 内存才能让工作集完全驻留。2GB 或 4GB 内存的机型(RosCloud-01、RosCloud-02、LAX-STARTER、LAX-MICRO)在这类负载下会频繁触发磁盘换页,查询耗时可能上升一个数量级。替代方案:换 64GB 或 128GB 内存的机型,如云途 HK.DS.P(64GB,750 元/月,库存 5)与 HK.DS.S(128GB,800 元/月,库存 13),或 sixtynet 的 LAX-LARGE(16GB 内存、320GB 盘,133.33 美元/月)配合外置对象存储存放大表。
场景二:主要访客在国内,机房在洛杉矶或欧洲。 sixtynet 的 LAX 系列与 Residential 系列机房都在美国西海岸,物理距离决定了首字节时间不可能与亚洲节点相比。数据库查询哪怕只花 5ms,往返延迟也要叠加在每一个请求上。替代方案:改用亚洲机房,云途的 HK.DS 系列就是香港节点;国内访客占多数的站点应优先把数据库和应用都放在同一台亚洲机器上,避免跨洲查询。
场景三:需要按小时弹性扩容,突发流量大。 sixtynet 全部机型是按年计费(13 个机型均为 year 周期),年付意味着全年容量被锁定,无法在业务高峰临时扩容,闲置月份的钱也拿不回来。替代方案:按月计费的 RosCloud 与云途系列,RosCloud 全部 6 档为 month 周期,云途 9 档也为 month 周期,可随用随付。
场景四:需要独立 IP 支撑多站点。 云途的 DS.ES.A、DS.ES.F、HK.DS.M 三款库存字段显示为 0,DS.ES.C 与 DS.ES.D 库存为 1,意味着部分型号当前无可购库存;sixtynet 与 RosCloud 的库存字段为空,实际库存需以官网为准。替代方案:下单前先在商品页确认库存,选库存明确大于 1 的型号,云途这边 HK.DS.S(库存 13)与 HK.DS.P(库存 5)相对宽松。
场景五:只要最低成本跑一个纯读的小库。 如果数据量在 5GB 以内、并发查询量很低,RosCloud-01(19.99 美元/月,1GB 内存、20GB 盘、1024GB 流量)完全够用。替代方案:无——这个场景下继续降配没有意义,再低就是共享型虚拟主机,失去 VPS 的隔离性。
场景六:机房位置必须靠近特定区域且要中国优化线路。 sixtynet 的 Los Angeles China Unicom-Premium 是年付 2500 美元(折合 208.33 美元/月)的中国联通优化线路,带宽仅 100Mbps,商品库里没有内存与磁盘字段数据,属于专线型产品而非通用 VPS。替代方案:普通 LAX 系列带宽 2000–10000Mbps,走 BGP 路由,成本低得多。
九、常见报错与排查手册

报错:ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (111)。 连接被拒绝。依次排查:服务是否在跑(systemctl status mysql)、端口是否监听(ss -lntp | grep 3306)、是不是只有 root 能用 socket 连接。先用 sudo mysql 试,能进就说明是认证方式或 bind-address 问题。
报错:ERROR 1045 (28000): Access denied for user 'appuser'@'localhost'。 密码错或账号的 host 部分对不上。CREATE USER 时 host 写的是 127.0.0.1 就只能用 -h 127.0.0.1 连,用 localhost 会走 socket 匹配另一条规则。用 SELECT user,host FROM mysql.user; 看清实际存在的组合。
报错:ERROR 2002 (HY000): Socket '/var/run/mysqld/mysqld.sock' (2)。 socket 文件不在预期位置,通常是改了 socket 配置或目录权限不对。sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld 修复。
报错:数据库进程莫名消失,日志里有 Killed process。 OOM Killer 干的。先 dmesg -T | grep -i oom 确认,再 journalctl -u mysql --since "1 hour ago" | tail -50 看被杀前的内存占用。缓解办法:加 swap、降低 innodb_buffer_pool_size、把 max_connections 调到 100 以下。
报错:mysqldump: Got error: 1044: Access denied for user 备份某个库。 账号权限不够。用 root 备份,或给备份账号单独授权 SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, RELOAD。
报错:ERROR 1114: The table 'xxx' is full。 磁盘满了,不是表本身满了。df -h 确认,然后清理 binlog:PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);,同时检查备份脚本是不是把根分区撑爆了。
报错:连接数报 Too many connections。 应用开了连接池但数据库 max_connections 更小。检查 SHOW STATUS LIKE 'Threads_connected'; 和 SHOW VARIABLES LIKE 'max_connections';,统一两边的口径,并在应用层限制池大小。
报错:ERROR 1047 (08S01): Unknown command '...' 或者命令被截断。 多半是贴命令时把换行也复制进去了,或者在不支持的客户端里执行了交互式命令。
报错:mysqldump: Received error code 28。 磁盘空间不足导致导出中断。导出大库前先 df -h /tmp 确认空间,或者直接流式导出到远程机器。
报错:应用连上数据库后报 Public Key Retrieval is not allowed。 MySQL 8 默认的 caching_sha2_password 认证和部分旧版驱动不兼容。在连接串里加上 allowPublicKeyRetrieval=true&useSSL=false,或者把账号改用 mysql_native_password:
ALTER USER 'appuser'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY '强密码';
报错:ERROR 1130 (HY000): Host 'xxx.xxx.xxx.xxx' is not allowed to connect to this MySQL server。 来源 IP 不在授权范围内。这恰恰说明绑定地址在起作用,是好现象——需要远程访问就走 SSH 隧道,别去放开公网端口。
按你的情况,下一步该看哪家
上面讲的是判断标准,但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条,直接去看对应的机型页比继续比价更快:
- 主要访客在国内、在意打开速度:先确认回程线路,再谈配置。看 iwebfusion 当前机型与价格
- 只是开发测试、临时用:按小时或月付,用完就删,别买年付。看 racknerd 当前机型与价格
价格与库存以商家页面当日显示为准,下单前建议先确认退款窗口与是否支持按月付费。
十、按你的情况该选哪一档:四类人的具体推荐

读完上面的判断标准,多数人最后还是想问一句"那我该买哪一档"。按实际情况对照下面四条,直接去看对应机型的当日报价比继续比价更快。
第一类:个人项目或学习用途,数据量在 5GB 以内。 直接选 RosCloud-01(19.99 美元/月,2 核 1GB 内存、20GB 盘、500Mbps 带宽、1024GB 月流量),内存单位成本 19.99 美元/GB 虽然是全表最高,但绝对总价最低,配 4GB swap 后跑 MySQL 加一个轻量应用完全够用。按月付,跑完就删,别年付。
第二类:中小生产业务,数据库 20GB–40GB,需要正常并发。 按工作集公式至少需要 52GB 内存才能让 20GB 数据完全驻留,实际选 64GB 内存档:云途 HK.DS.P 是 64GB 内存、1024GB 盘、2000Mbps 带宽、40000GB 流量,月付 750 元,库存 5;若需要更宽裕的余量且磁盘要放大对象,HK.DS.S 是 128GB 内存、6000GB SAS HDD、40000GB 流量,月付 800 元,库存 13,内存单位成本 6.25 美元/GB 折算下来是同类里最低的一档。
第三类:数据量大、读多写少、以归档和分析为主。 sixtynet 的存储型机型是明显更省的选择:LAX-Storage-1TB 年付 700 美元(折合 58.33 美元/月),8 核 8GB 内存、1000GB 盘、10000Mbps 带宽、15000GB 月流量,磁盘单位成本 0.058 美元/GB 是全表最低;LAX-Storage-500G 年付 400 美元(折合 33.33 美元/月),4 核 4GB 内存、500GB 盘、10000Mbps 带宽、10000GB 流量,磁盘单位成本 0.067 美元/GB。把大表和备份放这类机型,业务库放内存型,混合架构能把总账算到最低。
第四类:主要访客在国内,且要弹性伸缩。 选云途的 HK 节点(HK.DS.M 月付 350 元,32GB 内存、480GB 盘、1000Mbps 带宽、10000GB 流量,库存 0;HK.DS.B 月付 1200 元,128GB 内存、2000GB 盘,库存 0),并优先选带宽 2000Mbps 的 DS.ES.C(64GB 内存、800GB 盘、40000GB 流量,月付 700 元,库存 1)。机房位置对国内访客的打开速度影响远大于多两核 CPU,云途全部为月付周期,旺季加一台、淡季停掉,不必为峰值全年买单。
最后一句提醒:上面所有价格来自渠道库快照(快照时间 2026-11-04 11:20),库存字段随时变动,下单前请以商品页当日显示为准。数据库装好只是开始,真正的门槛是三个月后它还在稳定跑——所以备份和恢复演练的优先级,永远高于再升级一档配置。

喜欢
高兴
鬼脸
呵呵
无聊
伤心