EntityFrameworkCore 与 Oracle NLS 参数性能问题深度解析

问题背景

在使用 EntityFrameworkCore 连接 Oracle 数据库时，当会话设置了 NLS_COMP = LINGUISTIC 和 NLS_SORT = BINARY_CI 参数后，查询性能会出现显著下降。这个问题不仅出现在 EF Core 中，直接使用 ADO.NET 也会遇到相同情况。

核心现象

开发者在测试中发现以下关键现象：

1. 在数据库工具（如 DBeaver、PL/SQL Developer）中执行相同的查询，性能表现良好（5-20ms）
2. 在 .NET 应用中执行时，当使用 LINGUISTIC + BINARY_CI 组合时，查询时间显著增加（约500ms）
3. 小数据量查询或只取少量行时（如使用 Take(1)），结果返回迅速
4. 执行计划在不同环境下表现不一致

测试环境搭建

为重现问题，开发者创建了以下测试环境：

1. 创建测试表：

CREATE TABLE app."Customer" (
  "Id" NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,
  "Name" NVARCHAR2(254),
  PRIMARY KEY ("Id")
)

2. 添加两种索引：

CREATE INDEX app."IX_Customer_Name_NLS" ON app."Customer" (NLSSORT("Name", 'NLS_SORT=BINARY_CI'))
CREATE INDEX app."IX_Customer_Name" ON app."Customer" ("Name")

3. 插入200万条测试数据

性能测试结果

通过四种不同的 NLS 参数组合测试，发现：

• BINARY+BINARY：约10ms
• LINGUISTIC+BINARY：约10ms
• BINARY+BINARY_CI：约10ms
• LINGUISTIC+BINARY_CI：约500ms

深入分析

执行计划差异

通过分析执行计划，发现：

1. 在数据库工具中：

   • 使用参数化查询时，索引正常工作
   • 执行计划显示使用了 IX_Customer_Name_NLS 索引

2. 在 ADO.NET 中：

   • 执行计划显示全表扫描（TABLE ACCESS FULL）
   • 索引未被有效利用

3. 在 EF Core + ADO.NET 中：

   • 执行计划显示使用了索引
   • 但实际性能与全表扫描相当

技术要点总结