云服务器
在 2 核 4G 的服务器环境下，对于绝大多数个人博客场景，强烈推荐使用 SQLite。
除非你有非常特殊的并发写入需求或需要复杂的分布式架构，否则 SQLite 是更优的选择。以下是详细的对比分析和决策建议：
1. 核心结论：为什么首选 SQLite？
- 资源占用极低：SQLite 是一个嵌入式数据库，没有独立的进程（Daemon），直接由应用程序调用。它几乎不消耗额外的 CPU 和内存资源来维持服务运行。相比之下，MySQL 即使空闲状态也需要常驻一个进程，占用一定的内存（通常几百 MB）和 CPU 上下文切换开销。
- 部署与维护简单：SQLite 只是一个文件，不需要安装数据库服务、配置用户权限、优化参数或处理主从复制。对于个人博客，这意味着“零运维”成本。
- 性能足够：对于个人博客这种读多写少（Read-Heavy）的场景，SQLite 的性能完全够用。2 核 4G 跑 SQLite 可以轻松支撑每天数万甚至数十万 PV 的访问量（取决于应用层的缓存策略）。
- 备份方便：备份 SQLite 只需要复制那个
.db文件即可，无需使用mysqldump等复杂命令。
2. 详细对比分析
| 维度 | SQLite | MySQL (5.7/8.0) | 对 2 核 4G 环境的影响 |
|---|---|---|---|
| 架构模式 | 嵌入式库 | 客户端/服务端 (C/S) | SQLite 无网络协议开销，CPU 效率更高。 |
| 内存占用 | 极低 (仅应用所需) | 较高 (Buffer Pool + 进程开销) | MySQL 可能占用 300MB-600MB+ 内存，影响其他服务（如 Nginx/PHP）。 |
| 并发写入 | 较弱 (文件级锁) | 强 (行级锁) | 个人博客极少有同时多人编辑同一篇文章的情况，SQLite 的锁机制不是瓶颈。 |
| 并发读取 | 优秀 (支持多读者) | 优秀 | 两者在读取上差异不大，但 SQLite 无网络传输延迟。 |
| 维护成本 | 低 (无配置) | 中/高 (需调优、监控、安全加固) | 2 核 4G 下，省下的运维精力用于提升代码质量更重要。 |
| 扩展性 | 单机文件限制 | 支持集群、分库分表 | 个人博客生命周期内很难遇到需要分库分表的规模。 |
3. 什么时候应该选择 MySQL？
虽然推荐 SQLite，但如果你的博客具备以下特征，则应选择 MySQL：
- 极高的并发写入：例如博客集成了实时评论系统，且预计会有大量用户在同一秒内提交评论（这种情况在个人博客极罕见）。
- 需要复杂的存储过程或触发器：虽然 SQLite 也支持部分功能，但 MySQL 在这方面的生态更成熟。
- 多语言/多应用共享数据：如果你计划用 Python、Go、Java 等多个不同语言的项目共享同一个数据库，MySQL 作为独立服务更合适。
- 未来规划明确：如果你确定博客会在半年内膨胀到百万级用户，并且已经规划好了云原生架构（K8s + 云数据库 RDS），那么现在直接上 MySQL 可以省去迁移成本。
4. 针对 2 核 4G 环境的优化建议
无论你选择哪种数据库，在这个配置下，应用层优化比数据库选型更能提升体验：
- 开启 Redis 缓存：这是最重要的。将热点文章、首页列表、评论数等放入 Redis。这样即使数据库负载很高，90% 以上的请求也会直接命中缓存，数据库几乎只负责写操作。
- 静态化生成：如果使用的是 WordPress、Hexo、Hugo 或 Pelican 等静态/半静态博客，尽量将内容生成 HTML 静态文件，由 Nginx 直接交付，数据库仅用于后台管理。
- 数据库连接池：如果使用 PHP/Python/Node.js，确保配置合理的连接池，避免频繁建立新连接。
总结建议
直接选用 SQLite。
在 2 核 4G 的配置下，SQLite 能为你节省宝贵的内存资源给 Web 服务器（Nginx/Apache）和应用进程（PHP/Python/Go），从而让网站运行得更流畅。它的性能足以支撑个人博客全生命周期的流量，且极大地降低了技术门槛和维护成本。只有当你的博客真正成长为大型社区时，再考虑迁移到 MySQL 也不迟。