PHPWP博客在 1 核 1G（1 vCPU, 1GB RAM） 的极限配置下，SQLite 是绝对更合适的选择，而 MySQL 在此环境下运行会非常吃力甚至无法启动。
以下是针对该硬件配置的详细对比分析：
1. 资源消耗对比
| 特性 | SQLite | MySQL (InnoDB 引擎) |
|---|---|---|
| 内存占用 | 极低。作为库文件直接嵌入应用，无需独立进程，空闲时几乎不占内存。 | 高。即使空载，MySQL 守护进程通常也会占用 150MB – 300MB+ 内存。若开启缓冲池（innodb_buffer_pool_size），默认配置极易耗尽 1G 内存。 |
| CPU 占用 | 低。无网络协议栈开销，调用即执行。 | 中/高。需要处理 TCP/IP 连接、SQL 解析、权限验证等额外开销。 |
| 磁盘 I/O | 顺序写入为主，适合小事务。 | 频繁日志刷盘（Redo Log/Binlog）和索引维护，I/O 压力较大。 |
| 架构模式 | 嵌入式（Serverless）。 | C/S 架构（客户端/服务器）。 |
2. 为什么 1G 内存对 MySQL 很痛苦？
- 启动门槛：MySQL 8.0 版本在 1G 内存下启动非常困难。如果按照官方推荐设置
innodb_buffer_pool_size（通常建议为物理内存的 50%-70%），系统会立即触发 OOM Killer（内存溢出杀手），导致数据库崩溃或被系统强制杀掉。 - 配置妥协：为了在 1G 上跑通 MySQL，你必须进行极度激进的调优：
- 关闭 Swap（否则性能极差）。
- 将
innodb_buffer_pool_size限制在 64MB-128MB。 - 关闭不必要的插件和功能。
- 即便如此，一旦并发稍高或查询稍复杂，内存交换（Swap）会导致系统卡死。
- 连接开销：每个 MySQL 连接都会消耗一定的线程栈内存。1G 内存可能只能支撑几十个连接，而 SQLite 理论上可以支持更多并发读取（虽然写锁是串行的）。
3. SQLite 的优势与局限
✅ 优势（适合 1 核 1G）
- 零运维成本：不需要安装服务、配置用户、调整参数，代码里引用库即可。
- 极致轻量：安装包仅几 MB，运行时几乎不占资源。
- 单文件管理：整个数据库就是一个
.db文件，备份迁移只需复制文件。 - 适用场景完美契合：个人博客、小型工具、API 后端、物联网设备数据缓存、本地测试环境。
⚠️ 局限性（需要注意）
- 并发写入瓶颈：SQLite 使用文件级锁（File Locking），同一时间只能有一个写入操作。如果你的业务有高频并发写入（如多人同时发帖、高并发电商下单），SQLite 会成为性能瓶颈。
- 网络访问：SQLite 不支持远程网络直连（除非通过X_X或特殊封装），必须部署在同一台机器上。
- 数据完整性：在极端断电或崩溃情况下，恢复能力不如成熟的 ACID 事务机制完善的 MySQL（但在正常重启下表现很好）。
4. 最终建议
方案 A：首选 SQLite（推荐）
如果你的应用场景符合以下任一条件，请毫不犹豫选择 SQLite：
- 访问量较小（日 PV < 1 万，或并发用户 < 50）。
- 以读多写少为主，或者写入频率不高。
- 数据量在几十 GB 以内（SQLite 理论上限很大，但 1G 内存限制了缓存效率）。
- 你是个人开发者、初创项目初期或内部工具。
方案 B：勉强使用 MySQL（仅在特定条件下）
只有在以下情况才考虑在 1G 上强行运行 MySQL：
- 你的应用程序必须依赖 MySQL 特有的功能（如特定的存储过程、复杂的视图、特定的认证插件）。
- 你需要从外部网络直接连接数据库（且无法接受 SQLite 的架构限制）。
- 前提：你具备极强的 Linux 调优能力，能手动修改
my.cnf，严格限制内存分配，并接受随时可能因内存不足而宕机的风险。
💡 折中方案（进阶）
如果你担心未来流量增长，或者必须用 MySQL 但当前只有 1G：
- 先上 SQLite：快速上线，稳定运行。
- 预留升级路径：当主机升级到 2G 或 4G 时，再平滑迁移到 MySQL/MariaDB。
- 容器化隔离：如果使用 Docker，给 MySQL 容器设置严格的
memory_limit: 512m，防止它吃光宿主机内存导致 SSH 都连不上。
结论：在 1 核 1G 的限制下，SQLite 是唯一明智且稳定的选择。MySQL 在此配置下属于“由于资源不足导致的长期不稳定状态”，不建议生产环境使用。