低配服务器（1核2G）运行数据库时如何减少内存占用？

在 1 核 2G（约 1.8GB 可用内存）的服务器上运行数据库，属于典型的“资源受限”场景。要成功部署并稳定运行，核心策略是选择轻量级数据库、严格限制配置参数以及优化操作系统层面的内存管理。

以下是具体的优化方案，按优先级排序：

1. 数据库选型与架构调整（最关键）

首先，不要尝试在 2G 内存上运行重型数据库（如 MySQL 5.7/8.0 默认配置、PostgreSQL 默认配置）。

• 首选 SQLite：如果业务允许单机单文件，SQLite 是最佳选择。它没有独立的守护进程，内存占用极低（通常几 MB），且无需配置复杂的参数。
• 次选 MariaDB / MySQL (精简版)：如果必须用关系型数据库，建议使用 MariaDB（通常比 MySQL 稍轻）或 MySQL 5.7/8.0 的 Docker 镜像中的 tiny 版本。
  • 注意：避免使用 PostgreSQL，除非你经过极深度的裁剪，否则其默认内存开销容易超出 2G。
• 缓存层降级：如果应用需要 Redis 缓存，建议直接移除，或者改用 Redis 6.x 的 --maxmemory-policy allkeys-lru 并将最大内存限制在 300MB 以内。

2. 数据库核心参数调优（以 MySQL/MariaDB 为例）

这是决定生死的关键。你需要修改配置文件（my.cnf 或 mariadb.cnf），将内存占用强制锁定在安全范围内。

假设系统总内存 2GB，建议预留 400-500MB 给操作系统和应用程序，留给数据库的最大内存控制在 1.2GB – 1.4GB 之间。

关键参数配置示例：

[mysqld]
# 1. 基础字符集设置（减少元数据开销）
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

# 2. 连接数控制（防止高并发耗尽内存）
# 1 核 CPU 无法处理太多并发，设小一点
max_connections = 50

# 3. 缓冲池大小（InnoDB 的核心，占大头）
# 公式：(总内存 - 其他预留) * 0.5 ~ 0.6
# 2G 总内存 -> 建议设为 384M 到 512M
innodb_buffer_pool_size = 512M

# 4. 日志文件大小（减小磁盘 I/O 压力，降低内存映射需求）
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M

# 5. 临时表内存限制（防止大量临时表溢出到磁盘）
tmp_table_size = 32M
max_heap_table_size = 32M

# 6. 关闭不必要的功能
skip-name-resolve = 1  # 跳过 DNS 解析，提升性能并减少网络线程开销
performance_schema = OFF # 关闭性能监控，节省少量内存
slow_query_log = 0     # 生产环境若无必要可关闭，或仅开启慢查询

# 7. 交换分区（Swap）强制启用（见下文第 4 点）

3. 操作系统层面的优化

Linux 内核对内存的管理机制直接影响数据库的稳定性。

• 启用 Swap（虚拟内存）：
  在 2G 内存下，必须配置 Swap。虽然 Swap 会降低性能，但它能防止 OOM Killer（内存溢出杀手）直接杀掉数据库进程导致服务中断。

  • 操作：创建一个 2GB 的 Swap 文件。

    
    # 创建 2G swap 文件
    dd if=/dev/zero of=/swapfile bs=1M count=2048
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile

  设置 Swappiness（优先级）

  10 表示尽量不使用 swap，100 表示优先使用 swap。

  在 DB 场景下，建议设为 10 或 60，平衡性能和防崩溃

  sysctl vm.swappiness=10
  echo "vm.swappiness=10" >> /etc/sysctl.conf

  
  *注意*：即使有 Swap，也要确保上述数据库参数限制了内存上限，避免 Swap 频繁交换导致系统卡死。

• 关闭透明大页（Transparent Huge Pages, THP）：
  THP 在某些数据库场景下会导致严重的延迟抖动甚至内存泄漏。

  # 检查状态
  cat /sys/kernel/mm/transparent_hugepage/enabled
  # 输出应为 [always] madvise never，如果不是 always，需调整
  
  # 临时关闭
  echo never > /sys/kernel/mm/transparent_hugepage/enabled
  echo never > /sys/kernel/mm/transparent_hugepage/defrag
  
  # 永久生效需写入 rc.local 或 systemd 服务

• 禁用不需要的服务：
  清理服务器上的非必需服务（如 Avahi, Bluetooth, CUPS 等），释放宝贵的内存。

4. 应用层配合

数据库只是整个链路的一环，应用层的优化同样重要。

• 连接池管理：确保应用端的数据库连接池（如 HikariCP, Druid）设置合理的 maximumPoolSize。对于 1 核服务器，连接池大小最好控制在 10-20 之间，不要超过 50。
• SQL 优化：
  • 避免全表扫描（添加索引）。
  • 避免 SELECT *，只查询需要的字段。
  • 避免在 SQL 中进行复杂的计算或函数操作，尽量在应用层处理。
• 定期清理：如果数据库中有历史日志表或临时表，编写定时任务定期归档或删除。

5. 监控与兜底策略

由于资源紧张，必须建立监控报警。

• 监控指标：重点关注 MemFree, SwapUsed, InnodbBufferPoolReads。
• OOM 保护：虽然启用了 Swap，但如果物理内存彻底耗尽，Linux 仍可能触发 OOM。可以在启动脚本中设置 ulimit 限制，或者使用 cgroups 限制数据库进程的内存上限（例如限制为 1.5G），这样当达到上限时，数据库会报错而非拖垮整个系统。

总结建议清单

1. 数据库：优先 SQLite，其次 MariaDB/MySQL (Tiny)。
2. 配置：innodb_buffer_pool_size 设为 512M，max_connections 设为 50。
3. 系统：必须开启 2G Swap，关闭 Transparent Huge Pages。
4. 运维：限制应用连接池大小，定期清理无用数据。

通过这套组合拳，你可以在 1 核 2G 的服务器上稳定运行轻量级数据库服务，支撑中小规模的 Web 应用或 API 接口。