ASP.NET Core中SQLite与PostgreSQL性能对比：批量更新延迟问题

阿华AIGC实验室

2026-5-19

解决EF Core中并发切换值的性能问题（SQLite vs PostgreSQL）

嘿，这个并发更新的坑我之前也踩过！让我来给你拆解下问题根源，还有为啥PostgreSQL会给你带来“震惊”的结果。

先说说SQLite的延迟问题

SQLite本质是单文件数据库，它的写入机制是独占式全局锁——同一时间只能有一个写入操作执行，所有后续的写入请求都必须排队等待锁释放。你的业务场景是10次并发请求，它们会依次排队执行，哪怕每个请求本身只需要几十毫秒，加起来总延迟就会接近1秒，这就是你看到的“所有请求约1000ms同时返回”的原因。SQLite适合轻量、低并发的场景，高并发写入本来就不是它的强项。

PostgreSQL的“震惊”结果为啥会出现？

PostgreSQL采用的是多版本并发控制（MVCC）+行级锁机制，和SQLite的全局锁完全不同：

写入操作只会锁定被修改的那一行数据，不会阻塞其他行的读写
并发的写入请求会排队等待目标行的锁，但因为锁粒度极细，数据库处理锁的效率极高

所以10次并发请求的处理时间会大幅降低，可能从1秒直接降到几十毫秒，这种性能提升确实会让人感到震惊！不过这里要提醒你：如果你的更新逻辑是“先查询再修改”（比如先把实体加载到内存，切换值再保存），那还是可能出现丢失更新的问题——比如两个请求同时读到值为0，都改成1，最终结果还是1，而不是预期的0。

正确的并发处理方案

方案1：使用原子更新（推荐）

直接让数据库执行原子性的更新操作，不要先加载实体到内存。用EF Core的ExecuteUpdateAsync可以直接生成原子SQL：

await dbContext.YourEntities
    .Where(e => e.Id == targetId)
    .ExecuteUpdateAsync(s => 
        s.SetProperty(e => e.Value, e => 1 - e.Value)
    );

这会生成类似这样的SQL：

UPDATE "YourEntities" SET "Value" = 1 - "Value" WHERE "Id" = @p0;

数据库层面保证这个操作是原子的，完全避免并发冲突，性能也最优。

方案2：乐观并发控制（适合需要先读取数据的场景）

如果你的业务逻辑必须先读取当前值再修改，那可以用EF Core的乐观并发机制：

给实体添加并发检查属性（或者用RowVersion）：

public class YourEntity
{
    public int Id { get; set; }
    public int Value { get; set; }
    // 用当前值做并发检查，或者用RowVersion的byte[]类型
    [ConcurrencyCheck]
    public int Value { get; set; }
}

在保存时捕获并发异常并重试：

public async Task ToggleEntityValueAsync(int targetId)
{
    bool updateSuccess = false;
    while (!updateSuccess)
    {
        try
        {
            using var dbContext = new YourDbContext();
            var entity = await dbContext.YourEntities.FindAsync(targetId);
            if (entity == null) throw new KeyNotFoundException("目标记录不存在");
            
            entity.Value = 1 - entity.Value;
            await dbContext.SaveChangesAsync();
            updateSuccess = true;
        }
        catch (DbUpdateConcurrencyException)
        {
            // 遇到并发冲突，短暂延迟后重试
            await Task.Delay(10);
        }
    }
}