云服务器
是的，对于小型项目而言，SQLite 通常比 MySQL 更节省内存。这主要源于两者架构设计的根本差异：
核心原因对比
| 特性 | SQLite | MySQL（典型部署） |
|---|---|---|
| 架构模式 | 嵌入式库（无独立进程） | 客户端-服务器（C/S）架构 |
| 常驻内存 | 仅当前连接/操作时占用内存，用完即释放 | 即使无查询，守护进程（mysqld）也持续占用内存（如 innodb_buffer_pool 默认常设几百 MB） |
| 进程开销 | 0 个额外进程（代码直接链接库） | 至少 1 个主进程 + 可能多个线程/子进程 |
| 适用场景 | 本地文件、单用户/低并发、移动端、嵌入式设备 | 多用户、高并发、网络访问、需要复杂权限管理 |
实际影响示例
- SQLite：一个简单的小型 Web 应用（如博客后台），启动后几乎不占额外内存；仅在处理查询时临时分配所需内存。
- MySQL：即使只运行一个简单的查询，
mysqld进程也可能常驻 50MB–200MB+ 内存（取决于配置，尤其是 InnoDB 缓冲池）。
注意事项
虽然 SQLite 在内存上更高效，但需注意其限制：
- ❌ 不支持高并发写操作（同一时间只能有一个写者）
- ❌ 无原生网络协议支持（需通过X_X或封装实现远程访问）
- ❌ 不适合需要细粒度权限控制或审计的场景
✅ 结论：如果你的项目是小型的、单机部署、读写并发不高（如个人工具、原型系统、移动 App、IoT 设备），SQLite 是更轻量、更省内存的选择。若未来有扩展为多用户/高并发的需求，可考虑后期迁移到 MySQL/PostgreSQL。