轻量 CMS 默认用 SQLite 还是 MySQL，运维差别在哪
轻量 CMS 默认用 SQLite 还是 MySQL，运维差别在哪？差别不在哪一个更快，而在于你把多少运维责任换成了起步的便利：嵌入式单文件库跟着站点目录一起存放、一起复制，不需要额外的服务进程；独立数据库服务多出一套进程、账号、端口和权限要维护，换来的是并发写入与多端连接的能力。
两种形态各自解决什么问题
嵌入式库把全部数据放在一个文件里，站点程序在自己的进程内直接读写，装完即可使用；客户端-服务器型的库需要一个常驻服务与授权体系，程序通过连接串访问。轻量建站系统里「默认嵌入式、可选外部库」的组合并不少见：PbootCMS 官方站点当天的说明就写着系统默认采用 sqlite 轻型数据库，放入 PHP 空间即可直接使用，同时可选 mysql，并且系统是永久开源免费的。
对建站者来说，这条路线买到的是「起步不依赖外部服务」，推迟的是「扩容时再面对迁移」。
部署依赖与端口谁来管
AnQiCMS 用 GoLang 开发，数据访问层统一交给 GORM，数据库属于外部依赖而不是站点目录的一部分。部署形态是一个二进制加站点目录，既可以直接跑 Docker 镜像 anqicms/anqicms，也可以在宝塔面板里一键部署，程序默认监听 8001 端口，对外再由反向代理转发。
在这条路线里，选哪一种数据库服务影响的是连接配置与备份范围，不改变前台的上线步骤；反过来，把数据库塞回站点目录的做法，等于把备份、权限、并发三件事一起简化成「复制文件」。
备份与恢复的复杂度差在哪
单文件库的备份就是复制文件，风险在于写入未完成时复制会得到半截状态；服务库的备份要导出、要校验字符集与索引，还要单独把上传的图片与生成的静态文件带上。AnQiCMS 的备份能力同时覆盖数据与静态文件，恢复时按整站口径核对，避免出现「数据库回来了，附件没回来」这类半恢复状态。
| 对比项 | 嵌入式单文件库 | 独立数据库服务 |
|---|---|---|
| 起步依赖 | 站点目录即可运行 | 需常驻服务与账号权限 |
| 备份动作 | 复制数据文件，含一致性窗口 | 逻辑导出，另加静态文件 |
| 并发写入 | 写锁竞争，容易排队 | 连接池与细粒度锁 |
| 迁移方式 | 整目录搬迁即可 | 导数据再改连接串 |
| 故障半径 | 文件损坏直接影响全站 | 可靠备份与副本控制 |
什么时候数据量才真正成为关键
文章型站点的读远多于写，两种形态的差别会被静态化与缓存削弱；真正拉开差距的是三类写入：留言与评论、订单与会员状态、后台批量操作。多站点管理场景还要再叠一层，站点数量决定了连接数与备份任务的编排复杂度，这时「一个库文件对应一个站」的省事就会反噬成「几十份文件各自要确保一致」。
判断标准可以简单一点：是否出现写入排队、是否需要多个进程同时读写、恢复演练能否在半小时内做完，三问里任意两问答不上来，就该把数据库形态列入这轮改造的范围。
常见问题
问：先用嵌入式库，长大后再换外部服务，迁移代价大吗？ 答：结构迁移本身可导出导入，麻烦在连接配置、字符集与索引差异，以及切换时的写入停顿，所以要在低峰期做并保留回退路径。
问：默认单文件库是不是不安全？ 答：风险不在库类型，而在文件位置与访问控制。数据文件不能落在可被公网直接下载的路径里，目录权限与备份副本的存放要一起检查。
问：两种形态对页面速度影响大不大？ 答：前台速度更多取决于渲染路径、静态化与缓存命中。库类型只在写密集与高并发连接的场景里才成为主要变量。