云服务器
在 1 核 2G 这种配置较低（资源受限）的云服务器上，选择 SQLite 还是 MySQL，核心取决于你的应用场景、并发量以及对数据一致性的要求。
直接给出结论：
- 绝大多数个人项目、小型应用、低频访问场景：SQLite 是更合适的选择。
- 需要高并发写入、多用户同时操作、或必须保证严格 ACID 事务的场景：MySQL 是唯一选择，但需要极度的优化和监控。
以下是详细的对比分析和建议：
1. 资源消耗与性能表现
| 特性 | SQLite | MySQL (InnoDB) | 1 核 2G 环境下的表现 |
|---|---|---|---|
| 内存占用 | 极低。通常只需几 MB 到几十 MB，无需独立进程守护。 | 较高。即使空闲状态，MySQL 守护进程 + 缓冲池也常占用 100MB+。 | SQLite 胜出。2G 内存可以留出更多给操作系统缓存和应用程序本身。 |
| CPU 开销 | 低。无网络通信开销，直接在进程内执行 SQL。 | 中/高。涉及网络协议栈、连接握手、线程调度等开销。 | SQLite 胜出。单核 CPU 在处理复杂查询时，SQLite 的响应延迟更低。 |
| 并发机制 | 文件锁。同一时间只能有一个写操作，读操作可并发。 | 行级锁。支持高并发读写，但锁竞争会消耗大量 CPU。 | SQLite 在高频写入下会阻塞。如果并发写入超过每秒几次，SQLite 会频繁报错 database is locked。 |
| 部署复杂度 | 零。只有一个数据库文件，无需安装服务，无需配置端口。 | 高。需安装服务、配置用户权限、调整参数（如 innodb_buffer_pool_size）。 |
SQLite 运维成本几乎为零。 |
2. 场景化决策建议
✅ 选择 SQLite 的情况
如果你的应用符合以下特征，SQLite 是最佳方案：
- 单机应用：数据主要在一个服务器上读写，不需要分布式集群。
- 低并发：日访问量在几千以内，或者并发写入请求很少（例如：博客后台、个人笔记、内部工具、IoT 设备本地存储）。
- 读多写少：大部分时间是查询数据，偶尔更新。
- 开发/测试阶段：希望快速部署，不想处理数据库服务的启动、备份和连接问题。
- 离线能力：应用需要具备一定的离线运行能力（虽然云主机不离线，但架构设计类似）。
注意：SQLite 不支持“多人同时写入”。如果两个请求同时尝试修改数据，后到的请求会失败。对于 1 核 2G 机器，只要控制并发写入量，这通常不是问题。
⚠️ 选择 MySQL 的情况
如果你的应用符合以下特征，必须使用 MySQL，但需注意风险：
- 高并发写入：有实时交易、即时通讯记录写入等高频写入需求。
- 多进程/多线程应用：Web 服务器有多个 Worker 进程同时向数据库提交写请求。
- 严格的 ACID 事务：需要跨表、跨会话的复杂事务回滚机制（虽然 SQLite 也支持事务，但在极端并发下不如 MySQL 稳健）。
- 未来扩展性：计划未来将数据库迁移到独立的数据库服务器，现在先跑起来验证逻辑。
⚠️ 1 核 2G 跑 MySQL 的生存指南：
如果必须用 MySQL，必须进行严格调优，否则极易 OOM（内存溢出）导致宕机：
- 关闭非核心功能：禁用慢查询日志、二进制日志（Binlog），除非你有明确的审计需求。
- 限制 Buffer Pool：这是关键！默认 MySQL 会尝试占用大量内存。需要在
my.cnf中设置innodb_buffer_pool_size = 512M或更小（根据剩余内存计算，建议预留 200-300M 给 OS 和其他应用）。 - 限制连接数：设置
max_connections = 20左右，防止连接风暴耗尽 CPU。 - 使用轻量版：考虑使用 MariaDB 或 MySQL 的精简版本，甚至考虑 Docker 容器隔离资源。
3. 最终推荐策略
针对 1 核 2G 的配置，我的建议如下：
-
首选方案：SQLite
- 对于 90% 的个人开发者、小工具、原型系统，SQLite 能提供比 MySQL 快得多的响应速度，且稳定性极高。
- 代码适配：现代框架（如 Django, Flask, Go, Node.js）对 SQLite 的支持非常完美，切换成本几乎为 0。
-
备选方案：MySQL (仅当必要)
- 只有当你明确知道业务逻辑中存在高频并发写入，或者团队技术栈强制要求 MySQL 生态时，才选择它。
- 折中方案：如果担心 SQLite 的并发瓶颈，可以在应用层加一个队列（如 Redis 或简单的文件锁）来串行化写入请求，这样也能利用 SQLite 的高性能。
总结：在没有特殊高并发写入需求的前提下，SQLite 是 1 核 2G 云主机的绝对王者。它能让你用最少的资源获得最高的性价比。