部署MySQL时，选择1核1G还是1核2G的配置更合适？

在云计算环境下部署 MySQL，1核2G 是绝对更优且更具性价比的选择，而 1核1G 在绝大多数生产或准生产场景下都是“自杀式”配置。

以下从内存机制、性能瓶颈、成本效益和实际场景四个维度进行深度解析：

1. 核心矛盾：MySQL 是内存密集型应用

MySQL（尤其是 InnoDB 引擎）对内存的依赖远高于 CPU。其核心组件 Buffer Pool 需要缓存数据和索引，以减少磁盘 I/O。

• 1G 内存的困境：

  • 操作系统本身（Linux）启动后通常占用 300MB~500MB 内存。
  • 剩余给 MySQL 的 Buffer Pool 可能不足 512MB。
  • 一旦数据量超过几百 MB，查询将频繁触发 Page Out/In（换页），导致严重的磁盘 I/O 等待，表现为响应时间从毫秒级飙升至秒级甚至超时。
  • 若开启 Swap（交换分区），系统性能会断崖式下跌，因为 SSD/NVMe 的速度远不及 RAM，且频繁读写会提速磁盘磨损。

• 2G 内存的优势：

  • 操作系统占用约 400MB~600MB。
  • 可为 MySQL 分配 1GB~1.5GB 的 Buffer Pool。
  • 对于中小型数据库（如 <5GB 的数据集），大部分热点数据可驻留内存，实现接近纯内存查询的性能，I/O 压力大幅降低。

2. 并发与连接开销

每个 MySQL 连接都会消耗一定的内存（thread stack + sort buffer + join buffer 等）。虽然这些是 per-thread 的，但在高并发场景下累积效应显著。

• 1核1G：最大并发连接数极低，稍多几个长连接或复杂查询就会 OOM（Out of Memory）或触发 Swap，服务不稳定。
• 1核2G：能支撑更多并发连接，即使出现临时排序操作，也有更大空间避免使用磁盘临时表。

3. 成本效益分析（国内云厂商视角）

以阿里云、腾讯云、华为云等主流厂商为例：

关键点：1C2G 的价格通常是 1C1G 的 1.5~2 倍，但性能提升可能是 3~5 倍甚至更高（因减少 I/O 等待）。用少量预算换取稳定性，是 IT 架构设计的基本原则。

4. 什么情况下可以考虑 1C1G？

仅当满足以下所有条件时，才勉强可用：

• 数据总量 < 1GB；
• QPS（每秒查询率）< 10；
• 无复杂 JOIN 或子查询；
• 用于开发/测试环境，非生产环境；
• 有严格的监控告警，允许偶尔重启恢复。

否则，强烈建议至少选择 1C2G。

5. 优化建议（如果预算确实受限）

如果你只能选 1C1G，必须采取以下措施缓解问题：

1. 禁用 Swap：通过 swapoff -a 和修改 /etc/fstab 永久关闭，避免系统因 Swap 而彻底卡死。
2. 精简 MySQL 配置：

   [mysqld]
   innodb_buffer_pool_size = 256M    # 不要设太大，避免 OOM
   max_connections = 50              # 限制最大连接数
   tmp_table_size = 16M
   max_heap_table_size = 16M

3. 使用 SSD 云盘：确保底层存储是高 IOPS 的 ESSD 或高性能云盘，减轻 I/O 压力。
4. 应用层缓存：引入 Redis 缓存热点数据，减少对 MySQL 的直接查询。

结论

选择 1核2G。
在云计算时代，内存成本低廉，而因内存不足导致的性能抖动、故障排查时间和用户体验损失远超硬件差价。1C2G 是 MySQL 部署的“最小可用稳定配置”，1C1G 仅适用于极端受限的非关键场景。