小型项目在1核2G环境下选择什么数据库更稳定？

在 1 核 2G（单核 CPU，2GB 内存）的极端资源受限环境下，选择数据库的核心原则是：轻量级、低内存占用、无复杂后台进程。

在这个配置下，传统的重型数据库（如 MySQL 默认配置、PostgreSQL 默认配置、MongoDB）如果未经过深度调优，极易出现 OOM（内存溢出）导致服务崩溃。

以下是针对不同场景的推荐方案及详细分析：

1. 首选推荐：SQLite

如果你不需要高并发写入或分布式部署，SQLite 是 1 核 2G 环境下的绝对王者。

• 稳定性：极高。它是一个服务器less（Serverless）的嵌入式数据库，没有独立的守护进程，直接作为应用程序库运行。
• 资源占用：极低。内存占用通常在几 MB 到几十 MB 之间，完全不会成为瓶颈。
• 优势：
  • 零配置安装，只有一个二进制文件或动态库。
  • 数据存储在单个文件中，备份和迁移极其方便。
  • 支持完整的 SQL 标准（ACID 事务）。
• 适用场景：小型博客、个人工具、内部管理系统、日志存储、移动端/边缘端应用。
• 注意：在高并发写入时会有锁竞争，但如果是小型项目（通常 QPS 较低），其性能完全足够。

2. 关系型网络服务首选：MariaDB (MySQL 分支)

如果你必须使用 C/S（客户端/服务端）架构，且需要远程连接，MariaDB 通常比 MySQL 更轻量，配合极致优化可以在 2G 内存下运行。

• 稳定性：良好，但需要严格限制内存参数。
• 资源优化策略（关键）：
  • 关闭不必要的功能：禁用 Query Cache（新版已移除）、InnoDB Buffer Pool 设置极小（例如 innodb_buffer_pool_size = 64M 或 128M）。
  • 限制连接数：设置 max_connections = 20，防止连接数过多耗尽内存。
  • 字符集：使用 utf8mb4 但避免大字段。
• 对比 MySQL：MariaDB 在某些版本中对内存管理更激进，且在相同配置下通常表现略优于官方 MySQL。
• 适用场景：需要多用户并发访问、有远程运维需求、依赖 PHP/Java 等生态的项目。

3. 文档型数据库首选：LiteDB (C#/.NET) 或 MongoDB (需极度精简)

• MongoDB：原生非常吃内存。在 2G 环境下，不建议直接使用官方 Docker 镜像或默认配置。如果必须用，需要将其作为嵌入式模式运行（Embedded Server），或者将 wiredTigerCacheSizeGB 强制设为 0.5 甚至更低，并限制 net.maxIncomingConnections。但这依然有风险，容易因缓存不足导致频繁磁盘 I/O 而变慢。
• LiteDB：如果你的技术栈是 .NET/C#，LiteDB 是完美的替代方案。它类似 SQLite，但是以 BSON 格式存储文档，无需服务器，内存占用极低。

4. 时序/日志类专用：TinyDB / InfluxDB (需精简)

• 如果是做简单的 IoT 数据采集或日志记录，TinyDB（纯 Python JSON 文件存储）或 SQLite + 时间戳索引 远比 InfluxDB 稳定。InfluxDB 在 2G 下很难维持高性能，容易 OOM。

综合决策建议表

核心避坑指南（针对 1 核 2G）

无论选择哪种数据库，以下操作是保证稳定的前提：

1. Swap 分区（虚拟内存）：
   • 必须开启 Swap。在 Linux 上创建一个至少 2GB 的 Swap 分区。虽然 SSD 速度不如内存，但在物理内存耗尽时，它能防止数据库进程被系统直接杀死（OOM Killer），这是“保命”的关键。
2. 禁止自动重启的疯狂重试：
   • 如果数据库挂了，由于内存不足，重启后可能瞬间再次 OOM。确保监控脚本能识别这种死循环。
3. Docker 限制：
   • 如果使用 Docker 运行数据库，务必设置 --memory="1g" 和 --cpus="1"，否则容器可能会尝试占满宿主机所有资源，导致整个机器卡死。
4. 定期清理与压缩：
   • 对于 SQLite，定期执行 VACUUM；对于 MariaDB，定期优化表。

最终结论

• 最稳妥、最省心的选择：SQLite。只要你的业务逻辑允许（非高并发写入），它是 1 核 2G 环境下的最佳解。
• 必须用服务端架构的选择：MariaDB，但请务必按照上述建议进行严格的内存参数裁剪，并配置 Swap。

建议行动：先尝试 SQLite。如果后续业务扩展发现需要复杂的权限控制或多节点同步，再考虑迁移到优化后的 MariaDB。