.NET本地Db数据库技术方案选型有哪些优势？

公司现有项目使用了LiteDB作为本地数据存储，但每次开机有较高的概率读取阻塞。 因为死锁或者损坏导致的阻塞问题，目前只能设置超时。在db读取超时后，部分情况可以删除文件、重建db解决，也有无法删除db文件的情况。 导致的技术债务造成了非常多的冗余维护工作量，需要基于常用的数据库及使用方式，重新做个技术选型确认 LiteDB，是一类NoSql的文档数据库，引用Nuget包LiteDB对接开发，社区litedb-org/LiteDB: LiteDB - A .NET NoSQL Document Store in a single data file 在Windows本地数据存储场景中主要有Sqlite、LiteDB、LocalDB几个主要选项 Windows本地数据库选型 .NET Windows 本地数据库中SQLite、LiteDB、LocalDB的对比，CodeX生成如下： 维度SQLiteLiteDBLocalDB (SQL Server Express LocalDB) 数据模型 关系型（SQL） 文档型（BSON） 关系型（SQL Server 子集） 语言/协议 SQL 类 NoSQL API / LINQ T‑SQL（完整 SQL Server 语法） 部署 单文件，零安装 单文件，零安装 需安装 LocalDB runtime 依赖 SQLite 引擎 纯 .NET（无需 native） SQL Server LocalDB 组件 体积/性能 极小、快 极小、快（适合小规模） 较大、重 并发能力 多读单写 多读单写 多用户/多连接更强 事务 支持 支持 支持（完整） ORM 支持 很成熟（EF Core） 限制（非 EF） 极好（EF Core） 跨平台 完全跨平台 完全跨平台 仅 Windows 典型使用场景 轻量关系型本地库 轻量文档型嵌入库 需要 SQL Server 兼容性的本地库 1. SQLite 特点： 单文件存储（关系型数据库），零安装 SQL 语法，支持事务、索引、视图（有限） EF Core 支持成熟 高度跨平台（Windows、Linux、Mac、Mobile） 适合： 轻量关系型数据 需要 SQL / ORM 的桌面应用 高兼容+小体积优先 劣势： 并发写能力有限（多读单写） 缺少部分高级 SQL Server 特性 2. LiteDB 特点： 纯 .NET 嵌入式文档数据库（BSON） 不依赖 native DLL 类 MongoDB 的使用体验 单文件存储 适合： 非结构化/半结构化数据 简单应用配置、缓存、日志、轻量数据持久化 不想写 SQL 劣势： 不支持 EF Core 社区生态小于 SQLite 并发/事务能力相对弱一些 3. LocalDB（SQL Server LocalDB） **特点： SQL Server Express 的轻量模式 完整 T‑SQL 语法 与 SQL Server 高度一致，便于迁移 支持丰富特性（存储过程、视图、触发器等） 适合： 开发/测试环境需要模拟 SQL Server 需要复杂 SQL、视图、存储过程 将来要迁移到 SQL Server 的桌面应用 劣势： 仅 Windows 需要安装 LocalDB 组件 体积大、启动相对慢 数据库选型建议 1. 死锁损坏问题 按上面收集的情况，litedb存在频繁的db死锁损坏问题 SQLite 是否也会卡死？对比分析 SQLite这类"卡死"及损坏问题概率会相对较少。 原因如下： 1. SQLite 有内置的 busy_timeout 机制，写锁冲突时会自动等待+重试，超时后返回错误，不会无限阻塞 2. WAL 模式下读写不互相阻塞，只有写-写冲突 3. 多个连接实例访问同一文件是 SQLite 的正常用法，而 LiteDB 在这种模式下就容易死锁 4. SQLite 的锁机制经过 20+ 年生产环境验证 根据已知的社区反馈，liteDb在并发读写这块有较多问题。LiteDB 的锁机制在高并发场景下天然脆弱，而 SQLite 的 WAL 模式能更好地支持并发读写，且生态更成熟、调试工具更丰富。 2.社区成熟度 考虑到社区成熟度的情况。LiteDb Github仓库已知大量死锁问题，Nuget引用量37.8M不算高；而Sqlite是windows客户端本地标准成熟的方案了 3.性能对比 拆成 5 个指标看： 冷启动延迟：SQLite/LiteDB 常更快；LocalDB 首次唤醒可能慢。