.NET Core中使用Dapper查询SQLite速度极慢问题求助

这问题我之前帮同事排查过几乎一模一样的情况，调试和生产环境性能差这么多，大概率是几个容易忽略的配置或环境差异导致的，给你梳理几个关键排查方向和解决办法：

1. 检查并优化SQLite连接字符串 #

这是最常见的罪魁祸首！调试模式下，开发环境可能默认启用了一些性能优化参数，但生产环境的连接字符串往往只是最基础的配置，导致每次查询都要做大量磁盘同步操作。

把你的连接字符串改成类似这样：

Data Source=你的数据库文件路径.db;Cache=Shared;Journal Mode=WAL;Synchronous=Normal

解释下关键参数的作用：

• Cache=Shared：启用共享缓存，多个连接可以复用同一个内存缓存，避免每次打开连接都重新加载数据库页到内存。
• Journal Mode=WAL：Write-Ahead Logging模式，这会极大提升读性能，因为读操作不需要等待写操作完成，同时减少磁盘IO次数。
• Synchronous=Normal：降低同步级别，默认的Full级别会强制每次写操作都等待磁盘确认，生产环境如果不是强一致性要求，改成Normal能大幅提速（如果允许少量数据丢失风险，甚至可以设为Off）。

2. 确认数据库文件的存储位置和权限 #

• 生产环境中数据库文件千万别放在网络共享盘或者IO性能差的存储上！调试模式下你用的是本地SSD，读写速度快，但生产环境如果是机械盘或者网络存储，性能差距会非常大。尽量把数据库文件部署到本地高速磁盘上。
• 检查运行程序的用户权限：比如如果是IIS部署，应用池的身份用户必须拥有数据库文件所在目录的读写权限。权限不足会导致SQLite每次操作都触发权限检查，甚至无法正确使用WAL模式，直接拖慢性能。

3. 更新SQLite相关依赖包 #

.NET Core 2.0对应的Microsoft.Data.Sqlite包可能有旧版本的性能问题，建议更新到兼容.NET Core 2.0的最新稳定版（比如2.2.6版本，因为.NET Core 2.0的支持截止到2.x系列）。旧版本的SQLite原生库可能没有一些关键的性能优化，更新后往往能解决不少隐性的性能问题。

4. 检查查询是否使用参数化并添加索引 #

虽然你说调试模式下快，但还是要确认：

• 你的查询是不是用了参数化查询？比如用connection.QueryFirstOrDefault("SELECT HtmlContent FROM Pages WHERE Id = @id", new { id = pageId })而不是拼接字符串。非参数化查询会导致SQLite每次都重新编译SQL语句，生产环境下累积起来就会慢很多。
• 确认查询的字段有没有加索引：比如如果是根据Id查询，那Id字段应该设为主键（自动加索引），如果是其他字段查询，手动创建索引能让查询速度瞬间提升。

5. 排查连接复用问题 #

SQLite的连接池机制和SQL Server不同，如果你每次查询都新建SqliteConnection然后立即释放，生产环境下可能无法有效复用连接。建议用依赖注入管理连接实例，或者在业务逻辑中尽量复用同一连接（注意线程安全，SQLite连接不是线程安全的，要保证单线程使用）。

先从连接字符串的优化开始试，这一步解决了大部分类似的性能问题。如果还不行，再逐步排查后面的点。

内容的提问来源于stack exchange，提问作者TidyDev