嵌入式数据库在很多桌面工具、移动应用和物联网设备中承担着本地数据持久化的任务。SQLite 和 SQL Server Compact 都属于无服务器模式的嵌入式数据库，但架构理念完全不同。SQLite 使用单文件加轻量级库的形式，不依赖任何外部服务；SQL Server Compact 则是一个独立的 DLL 组件，数据文件格式与 SQL Server 主版本并不兼容。选择哪一个，取决于你对可移植性、数据库大小和 .NET 集成深度的实际要求。

存储引擎与部署模型的本质区别

SQLite 的存储引擎是一个完整的 B-tree 实现，所有表、索引、触发器和元数据都存储在一个普通的磁盘文件里。这个文件可以被复制到任何支持 SQLite 的系统上直接打开，不需要安装数据库服务、配置监听端口或创建用户账户。它的库文件通常只有几百 KB，编译成动态链接库后可以被 C、C++、Java、Python、.NET 等几乎所有主流语言调用。部署时只需要带上一个原生库文件和数据库文件，真正的零配置。

SQL Server Compact 的数据文件默认扩展名是 .sdf，同样也是单文件存储，但它需要依赖一组 Microsoft 提供的 DLL，比如 sqlceca35.dll、sqlceoledb35.dll 等。部署时通常需要通过安装包把这些 DLL 注册到系统或放在应用程序目录下。更重要的是，SQL Server Compact 只支持 32 位进程，如果你在 64 位 IIS 或 64 位桌面程序中引用它，必须强制项目目标平台为 x86，否则运行时会出现无法加载 DLL 的错误。这一点在 IIS 上部署 ASP.NET 应用时经常被忽视。

从数据文件的最大尺寸来看，SQLite 理论上可以支持到 140 TB 左右的单库文件，而 SQL Server Compact 的单个数据库文件上限为 4 GB。如果业务数据增长超过 4 GB，SQL Server Compact 只能通过拆分数据库或定期归档来解决，SQLite 则没有这个负担。此外，SQLite 的文件格式完全公开且有官方文档，数据迁移到 PostgreSQL、MySQL 等服务器数据库时有成熟的导入工具；SQL Server Compact 的文件格式未公开，迁移只能通过 SQL 导出或 ADO.NET 逐表读取完成。

并发控制与事务行为差异

SQLite 默认使用数据库级写锁，同一时间只允许一个写事务执行，读操作可以在写事务进行时继续，但一旦写事务提交，所有等待的读写都会串行化。这种设计对移动端和桌面应用来说足够，但在多线程高并发写入的场景下会明显降低吞吐量。SQLite 提供了 WAL（Write-Ahead Logging）模式来缓解读写锁竞争，WAL 模式下读和写可以真正并行，但需要额外的 -wal 和 -shm 文件，并且要求数据库文件所在目录支持共享内存映射。

SQL Server Compact 的并发控制基于行级锁和页级锁，内部实现了完整的事务隔离级别，包括 ReadCommitted、RepeatableRead 和 Serializable。它的锁粒度比 SQLite 细，在多用户同时写不同行时能获得更好的并发性能。不过 SQL Server Compact 毕竟不是服务器数据库，它最多只支持 256 个并发连接，而且每个连接都需要加载一份引擎代码到内存中。对于本地单进程内多线程访问的场景，SQL Server Compact 的表现比 SQLite 的默认模式略好，但差距并不大；一旦并发量上升，两者的瓶颈都会出现在磁盘 I/O 上。

事务日志方面，SQLite 在每次提交默认会执行 fsync 确保数据落盘，如果希望提高写入速度可以设置 PRAGMA synchronous=NORMAL 或 OFF，代价是崩溃后可能丢失最近几个事务。SQL Server Compact 同样支持事务日志但将其内置在 .sdf 文件内部，没有单独的日志文件，崩溃恢复由引擎自动完成。从数据安全性角度，两者都支持 ACID 事务，但 SQLite 的 WAL 模式在频繁断电场景下更容易出现 -wal 文件损坏，需要定期 checkpoint。

编程接口与平台支持对比

SQLite 的编程接口极其丰富，官方提供 C API，社区贡献了几乎所有语言的绑定。在 .NET 平台上，System.Data.SQLite 和 Microsoft.Data.Sqlite 都是成熟的 ADO.NET 提供程序，其中 Microsoft.Data.Sqlite 是微软官方维护的轻量级库，可以直接通过 NuGet 安装。下面是一个使用 Microsoft.Data.Sqlite 执行查询的示例：

using (var connection = new SqliteConnection("Data Source=mydata.db"))
{
    connection.Open();
    var command = connection.CreateCommand();
    command.CommandText = "SELECT name, age FROM users WHERE age > @age";
    command.Parameters.AddWithValue("@age", 18);
    using (var reader = command.ExecuteReader())
    {
        while (reader.Read())
        {
            Console.WriteLine($"{reader.GetString(0)} - {reader.GetInt32(1)}");
        }
    }
}

SQL Server Compact 的 .NET 提供程序是 System.Data.SqlServerCe，这个命名空间只支持 .NET Framework，不支持 .NET Core 或 .NET 5 以上的版本。在 .NET Core 和 .NET 6/7/8 中没有任何官方方式访问 .sdf 文件，只能通过 P/Invoke 调用底层 OLEDB 接口，复杂度非常高。这就意味着，如果你的新项目使用 .NET 8 或打算迁移到 Linux，SQL Server Compact 完全不可用。

平台覆盖方面，SQLite 支持 Windows、Linux、macOS、iOS、Android、嵌入式 RTOS 等几乎所有操作系统，且提供官方的预编译二进制文件。SQL Server Compact 官方只支持 Windows 桌面系统和 Windows Mobile/CE，对 Linux 或 macOS 没有任何官方支持。如果你需要开发跨平台应用或未来可能部署到容器环境，SQLite 是唯一合理的选择。

性能开销与资源占用实测

内存占用上，SQLite 的默认缓存大小约为 2 MB，可以通过 PRAGMA cache_size 调整。启动一个空连接几乎不消耗额外内存，打开数据库文件也只是映射文件头部分页。SQL Server Compact 每个连接会加载完整的引擎 DLL 并分配默认 640 KB 的缓冲池，但实际占用的内存通常比 SQLite 高出 30% 到 50%，尤其在进行大量查询时，SQL Server Compact 会保留更多的页缓存和元数据缓存。

写入性能方面，在批量插入场景下 SQLite 使用事务包裹 10000 条记录通常可以在几百毫秒内完成，而 SQL Server Compact 的批量插入由于需要维护更复杂的行级锁和事务日志，速度往往比 SQLite 慢 2 到 3 倍。读取性能上，对于简单的单表主键查询，两者差距不大；但如果查询涉及多表连接和子查询，SQLite 的查询优化器通常能生成更高效的执行计划，尤其是在索引利用不充分的情况下。SQL Server Compact 的优化器更接近 SQL Server 桌面版，对复杂 SQL 的解析能力有一定优势，但受限于 4 GB 数据量和单文件格式，这种优势并不明显。

下面是一个 SQLite 批量插入的 Python 示例，展示事务对写入性能的影响：

import sqlite3
conn = sqlite3.connect("benchmark.db")
cursor = conn.cursor()
cursor.execute("CREATE TABLE IF NOT EXISTS items (id INTEGER PRIMARY KEY, value TEXT)")
# 未使用事务：每次 execute 都隐式提交
for i in range(10000):
    cursor.execute("INSERT INTO items (value) VALUES (?)", (f"value{i}",))
# 使用事务：性能提升显著
conn.execute("BEGIN")
for i in range(10000, 20000):
    cursor.execute("INSERT INTO items (value) VALUES (?)", (f"value{i}",))
conn.commit()
conn.close()

这个例子中，未使用事务的 10000 次 INSERT 可能需要 10 秒以上，而使用事务后可以在 0.5 秒内完成。SQL Server Compact 也遵循相同的事务优化原则，但由于其内部锁管理更复杂，即使使用事务，批量插入速度仍落后于 SQLite。

迁移与维护的现实考量

SQL Server Compact 自 2013 年后就没有发布过新版本，微软官方已宣布其进入弃用状态，不再提供安全更新。这意味着使用 SQL Server Compact 的项目如果遇到安全漏洞或兼容性问题，只能自行修复或迁移。而 SQLite 由一个活跃的开源社区和商业公司共同维护，每年都会发布多个版本，修复漏洞并增加新特性。从长期维护角度看，SQLite 的可持续发展性远优于 SQL Server Compact。

如果现有系统仍在使用 SQL Server Compact 且无法立刻重写，建议优先做数据迁移。可以通过 SQL Server Management Studio 的导入向导或自己编写 ADO.NET 程序读取 .sdf 文件，将数据导出为 SQLite 数据库。下面是一个使用 C# 读取 SQL Server Compact 并导出到 SQLite 的简化迁移思路：

// 假设已引用 System.Data.SqlServerCe 和 Microsoft.Data.Sqlite
using (var srcConn = new SqlCeConnection("Data Source=old.sdf"))
using (var dstConn = new SqliteConnection("Data Source=new.db"))
{
    srcConn.Open();
    dstConn.Open();
    var cmd = srcConn.CreateCommand();
    cmd.CommandText = "SELECT id, name FROM users";
    using (var reader = cmd.ExecuteReader())
    {
        var insert = dstConn.CreateCommand();
        insert.CommandText = "INSERT INTO users (id, name) VALUES (@id, @name)";
        insert.Parameters.Add(new SqliteParameter("@id", SqliteType.Integer));
        insert.Parameters.Add(new SqliteParameter("@name", SqliteType.Text));
        while (reader.Read())
        {
            insert.Parameters["@id"].Value = reader.GetInt32(0);
            insert.Parameters["@name"].Value = reader.GetString(1);
            insert.ExecuteNonQuery();
        }
    }
}

这段代码在 .NET Framework 4.x 环境下可以运行，通过逐表迁移的方式将数据转移。对于索引、触发器和存储过程，SQL Server Compact 支持的存储过程有限，大部分业务逻辑都在代码层，迁移成本相对可控。

综合来看，新项目建议直接采用 SQLite，它拥有更广泛的社区支持、更好的跨平台能力和更小的资源占用。SQL Server Compact 仅适合维护遗留的 Windows 桌面程序，并且数据库规模必须在 4 GB 以内。对于已经使用 SQL Server Compact 的系统，应尽快制定迁移计划，避免技术债务进一步累积。