在1核2G的Linux服务器上部署MySQL有哪些优化建议？

在 1 核 2G（1 vCPU, 2GB RAM）的 Linux 服务器上部署 MySQL，资源非常紧张。如果不进行优化，MySQL 很容易因内存不足被系统 OOM Killer 杀掉，或因 CPU 满载导致服务不可用。

以下是针对该硬件环境的核心优化建议，按优先级排序：

1. 核心内存配置（最关键）

MySQL 默认会尝试分配大量内存用于缓冲池、临时表等。在 2G 内存下，必须严格限制 innodb_buffer_pool_size，否则极易触发 OOM。

• 总可用内存估算：Linux 内核 + 其他进程约占用 300MB-400MB。留给 MySQL 的安全空间约为 1.2GB – 1.4GB。
• InnoDB Buffer Pool：设置为物理内存的 50% – 60%。
  • 建议值：800M 到 1000M。
  • 公式参考：innodb_buffer_pool_size = 1000M (或 960M)。
• 其他关键参数调整：
  • tmp_table_size 和 max_heap_table_size：限制为 64M 或 128M，防止内存溢出。
  • sort_buffer_size、read_rnd_buffer_size、join_buffer_size：这些是每个连接独占的。务必调小，建议设为 1M – 2M。如果设置过大，并发稍高就会撑爆内存。
  • query_cache_size：直接关闭 (0)。查询缓存对现代 MySQL (5.7/8.0) 性能提升有限且容易成为瓶颈，在低配环境下是累赘。
  • max_connections：根据业务量设定，建议 50 – 100。不要设太大，否则每个连接都会消耗 buffer 内存。

推荐 my.cnf 片段 (适用于 MySQL 5.7/8.0)

[mysqld]
# 基础设置
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp

# 内存优化 (核心)
innodb_buffer_pool_size = 1024M  # 约 1GB，占可用内存的 70% 左右
innodb_log_file_size = 256M      # 日志大小，避免频繁刷盘

# 限制每个连接的内存开销
sort_buffer_size = 1M
read_rnd_buffer_size = 1M
join_buffer_size = 1M
thread_stack = 256K

# 临时表限制
tmp_table_size = 64M
max_heap_table_size = 64M

# 关闭查询缓存
query_cache_size = 0
query_cache_type = 0

# 连接数限制
max_connections = 80

# InnoDB 刷新策略 (减少 IO 压力)
innodb_flush_log_at_trx_commit = 2  # 牺牲少量安全性换取性能 (若数据非强一致可考虑)
sync_binlog = 0                     # 同样牺牲安全性，降低 IO 频率 (需权衡)

# 日志与错误
log_error = /var/log/mysql/error.log
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

2. 操作系统级优化

Linux 内核参数也需要配合 MySQL 进行微调。

• 增加 Swap 分区：
  • 虽然 Swap 慢，但在 2G 内存下，它是防止 MySQL 被杀死的最后一道防线。
  • 建议：创建一个 2GB – 4GB 的 Swap 文件。
  • 命令示例：

    dd if=/dev/zero of=/swapfile bs=1M count=2048
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile
    echo "/swapfile none swap sw 0 0" >> /etc/fstab

• 调整 Swappiness：
  • 让系统尽量少用 Swap，但又不完全禁用以防崩溃。
  • 建议值：vm.swappiness = 10 (默认通常是 60)。
  • 命令：sysctl vm.swappiness=10
• 大页内存 (HugePages)：
  • 对于 2G 机器，开启 HugePages 可能收益不明显甚至增加配置复杂度，通常建议保持默认，除非你发现 CPU 等待时间很高。

3. 数据库架构与 SQL 优化

硬件受限，软件层面必须“精打细算”。

• 索引优化：
  • 确保所有 WHERE、JOIN、ORDER BY 字段都有索引。
  • 避免全表扫描（Full Table Scan），这是 1 核 CPU 的杀手。
  • 使用 EXPLAIN 分析慢查询。
• 避免复杂计算：
  • 避免在数据库中做大量的字符串处理、正则匹配或复杂的数学运算。尽量在应用层（Java/Python/Go）完成。
• 读写分离（如果可能）：
  • 如果是单库，尽量将只读流量（如统计报表）分流到从库（如果有另一台机器），或者在业务低峰期执行重任务。
• 定期清理日志：
  • 监控 mysql-bin 二进制日志，及时清理过期的日志，防止磁盘写满导致服务挂起。

4. 监控与运维策略

• 安装轻量级监控：
  • 使用 htop 或 iotop 实时观察负载。
  • 安装 mysqldump 并编写脚本，每天凌晨自动备份到本地或其他存储（注意备份时加 --single-transaction 减少锁表）。
• 慢查询日志分析：
  • 开启 slow_query_log，每天分析一次 long_query_time 大于 1 秒 的 SQL，立即优化。
• 定时重启（可选）：
  • 如果运行一段时间后内存碎片严重，可以在业务低峰期（如凌晨 3 点）重启 MySQL 服务释放内存碎片。

5. 替代方案考量

如果经过上述优化，MySQL 依然无法满足业务需求（例如 QPS 过高或响应极慢），请考虑以下方案：

1. 降级存储引擎：如果不需要事务支持，部分场景可考虑使用 MyISAM（不推荐，除非特定场景），或者仅使用 InnoDB 但极度精简表结构。
2. 迁移到云托管版：购买最低配的 RDS 实例，通常比自建更稳定且包含自动维护。
3. 更换轻量级数据库：
   • SQLite：如果主要是单机读写，SQLite 性能极佳且无内存开销。
   • Redis：将热点数据全部放入 Redis，MySQL 仅作为持久化存储。
   • MariaDB：在某些版本中，MariaDB 对低配环境的优化略优于 MySQL，可以尝试替换。

总结

在 1 核 2G 上部署 MySQL，核心原则是“保守”：

1. 死守内存：innodb_buffer_pool_size 不超过 1GB，禁止大的 *_buffer_size。
2. 依赖 Swap：必须配置 Swap 防止 OOM。
3. SQL 质量：没有好的索引和优化 SQL，再多的内存也没用。

建议在上线前进行压力测试（如使用 sysbench），观察在模拟高并发下的表现，并根据实际报错动态调整参数。