Npgsql/EFCore.PG 项目中字符串包含查询性能优化指南

在使用 Npgsql 和 EFCore.PG 进行 PostgreSQL 数据库开发时，开发者可能会遇到字符串包含查询性能低下的问题。本文将深入分析这一问题的根源，并提供有效的解决方案。

问题现象

当执行类似 Where(b => names.Contains(b.Name)) 的 LINQ 查询时，EFCore.PG 会生成使用 = ANY(ARRAY[...]) 语法的 SQL 语句。在某些情况下，这种查询方式会比直接使用 = ANY('{...}') 语法慢 10 倍以上。

根本原因分析

经过深入调查，发现性能差异主要源于以下两个方面：

1. 数据类型不匹配：当数据库列定义为 bpchar 类型（固定长度字符）而查询参数被当作 text 类型处理时，PostgreSQL 无法使用索引进行优化。

2. EFCore 模型配置不足：如果未在 EF Core 模型中明确定义字符串属性的最大长度，EFCore.PG 会默认将其映射为 PostgreSQL 的 text 类型，而非更具体的 bpchar 或 varchar 类型。

解决方案

1. 正确配置 EF Core 模型

对于固定长度字符列，应在模型配置中明确指定类型和长度：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<YourEntity>()
        .Property(e => e.stt_rec_doitac)
        .HasColumnType("bpchar")
        .HasMaxLength(20); // 根据实际长度调整
}

2. 使用 Scaffold-DbContext 时的注意事项

当使用 Scaffold-DbContext 从现有数据库生成模型时，可能需要手动补充类型信息，因为自动生成的代码可能不会包含足够的类型细节。

3. 查询优化技巧

在无法修改模型配置的情况下，可以考虑以下临时解决方案：

-- 强制类型转换
stt_rec_doitac = ANY(ARRAY['A1000000002201362CT1']::bpchar[])

性能对比

通过实际测试，不同查询方式的性能差异明显：

1. 未优化查询（使用默认 text[] 类型）：约 300ms
2. 优化后查询（使用正确类型）：约 0.04ms

最佳实践建议

1. 始终在 EF Core 模型中明确定义字符串属性的类型和长度
2. 对于固定长度字符列，显式指定 HasColumnType("bpchar")
3. 定期检查生成的 SQL 查询计划，确保索引被正确使用
4. 考虑使用 PostgreSQL 的扩展统计信息来优化复杂查询

通过遵循这些建议，开发者可以显著提高包含字符串包含操作的查询性能，确保应用程序能够高效地处理大量数据。