SQLite 和 MySQL 的区别，小项目怎么选

2026-10-12 SQLite,MySQL,数据库选型,后端开发

有人问我后台为什么不用 MySQL，我说因为部署那台机器上没人管它。SQLite 和 MySQL 有什么区别，说到底不是性能高低，是一个文件和一个服务端的区别，小项目选哪个取决于你愿不愿意多养一个进程。

一、SQLite 和 MySQL 有什么区别：维度对比

| 维度 | SQLite | MySQL |

|---|---|---|

| 部署形态 | 一个文件，随程序走 | 独立服务端，要装要运维 |

| 并发写入 | 同一时刻只允许一个写入者 | 支持多个并发写入连接 |

| 备份方式 | 复制文件，但要注意写入时机 | 用工具导出，或做主从 |

| 数据迁移 | 文件拷走即可 | 需要导出导入，或改连接配置 |

| 运维成本 | 几乎没有 | 要管账号、连接数、磁盘、版本 |

| 适用规模 | 单机、低写入、中小数据量 | 多实例、高并发、需要横向扩展 |

表里最容易被忽略的是「并发写入」那一行。它不是性能差异，是能力差异，写不进去就是写不进去，调参救不了。

另外补一句关于备份的。文件方案看着简单，但要在没有写入的时候拿，否则拿到的可能是半截文件。服务端方案自带导出工具，代价是你得多养一个进程。

二、SQLite 适合谁

适合一个人或小团队维护的服务，部署在一台机器上。数据量在单机磁盘能承受的范围内。

也适合那些「先做出来再说」的阶段。你不用先花时间搭数据库环境，功能跑起来了再考虑换。

我自己的后台就属于这一类：单个 Go 进程，配上它自己那份数据文件。上线速度比数据库选型重要。

还有一类容易被忽略的适用者：本地工具、桌面软件、以及只在单机跑的数据处理脚本。这些场景里装一个数据库服务端纯属给自己找事。

三、MySQL 适合谁

适合多台机器同时对外提供服务的情况。哪怕当前只有一台，如果明确马上就要横向扩，也可以直接上。

还适合写入非常密集的场景，比如大量用户同时在提交数据。这类负载下 SQLite 的写入排队会变成实打实的等待。

以及那种需要多人协作运维、要分权限、要审计的环境。这些是服务端数据库自带的能力。

顺带说一句：如果团队里已经有 DBA 或者已有现成的数据库实例，那选它的边际成本很低，决策会更容易。

四、这里有个常见误判

很多人换数据库的理由是「以后数据会变多」，这个理由通常不成立。

数据条数变多，SQLite 加好索引一样能撑。真正撑不住的是并发写入，而不是数据量。

反过来也有误判：有人因为「SQLite 是玩具」就直接上服务端，结果花在运维上的时间比写业务还多，而实际并发只有个位数。

我给自己定的判断方式是问两个问题：这套服务未来会不会跑两个以上实例？写入会不会持续密集？两个都是否，就先别换。

五、我最后选了哪个，凭什么

我选了 SQLite。理由是我这边没有多实例，也没有高并发写入，而这两点正是 MySQL 的价值所在。

换来的好处是部署极简：备份、迁移、本地起一个测试环境，都是跟文件打交道。

代价我也清楚：写入要排队，代码里得把写操作收敛起来。这个代价我付得起。

如果哪天我的后台需要跑两个实例共享数据，我会换。判断标准是新需求，不是感觉。想清楚 SQLite 和 MySQL 有什么区别，其实就是在问自己有没有这两个需求。

常见问题

Q：SQLite 和 MySQL 的区别里，最关键的是哪一条？

A：并发写入能力。SQLite 同一时刻只有一个写入者，MySQL 支持多个并发写，这条决定了你的架构能不能横向扩。

Q：小项目先用 SQLite，以后能换成 MySQL 吗？

A：能。前提是你没把 SQL 写成只对某一种数据库有效的方言，业务代码通过接口访问数据会让迁移更容易。

Q：用 SQLite 会不会显得不专业？

A：选型看场景不看面子。单机低写入的场景用它，是省掉了一整块运维工作，不是偷懒。