为什么 LINQ 在我的查询中使用错误的数据类型，而它在 EF 架构中被正确声明？

Question

我的数据库架构默认使用 varchar。使用 EF(6) 代码优先方法，我通过将字符串的 ColumnType 设置为 varchar 来确保我的模型是正确的：modelBuilder.Properties<string>().Configure(p => p.HasColumnType("varchar"));

我正在使用 PredicateBuilder 来构建我的 where 子句，并且一切都按预期工作； LINQ 使用 varchar 数据类型创建参数化查询。我也尝试过不使用 PredicateBuilder：出现完全相同的问题。

但是，一旦我添加了一个 Select 语句，LINQ 突然决定将数据类型更改为 nvarchar，而我想不出任何理由。这当然会对我的查询产生严重的负面影响，因为 sql server 现在必须进行大量隐式转换，从而使我的索引无用。它现在是扫描表而不是搜索。

var ciPredicate = PredicateBuilder.New<InfoEntity>(true);
ciPredicate = ciPredicate.And(x => x.InfoCode == ciCode);
ciPredicate = ciPredicate.And(x => x.Source == source);

//varchar - N'@p__linq__0 varchar(8000),@p__linq__1 varchar(8000)'
var ciQuery2 = this.Scope.Set<InfoEntity>().Where(ciPredicate).ToList();

//varchar - N'@p__linq__0 varchar(8000),@p__linq__1 varchar(8000)'
var ciQuery3 = this.Scope.Set<InfoEntity>().Where(ciPredicate).GroupBy(x => new { x.Source, x.InfoKey }).ToList();

//varchar - N'@p__linq__0 varchar(8000),@p__linq__1 varchar(8000)'
var ciQuery4 = this.Scope.Set<InfoEntity>().Where(ciPredicate).GroupBy(x => new { x.Source, x.InfoKey }).ToList().Select(group => group
                    .OrderByDescending(x => x.InfoSeqNr)
                    .FirstOrDefault()
                );

//nvarchar - N'@p__linq__0 nvarchar(4000),@p__linq__1 nvarchar(4000)'
var ciQueryNvarchar = this.Scope.Set<InfoEntity>().Where(ciPredicate).GroupBy(x => new { x.Source, x.InfoKey })
                .Select(group => group
                    .OrderByDescending(x => x.InfoSeqNr)
                    .FirstOrDefault()
                ).ToList();

表定义：

CREATE TABLE Info(
  Id int NOT NULL,
  InfoKey int NOT NULL,
  Source varchar(50) NOT NULL,
  InfoCode varchar(50) NOT NULL,
  InfoDesc varchar(4000) NOT NULL,
  InfoSeqNr int NOT NULL
)

由于这只是一个查询的开始，我们不能在中间使用 ciQuery4 和 ToList()。

我一生都无法弄清楚为什么会发生这种情况，我们将不胜感激。

Answer 1

这似乎是 EF 中的一个错误......或者真的是这样吗？

我能够在 EF6.4.4 中通过 GroupBy 子句中的 select 语句重现这一点。单列GroupBy 和复合列GroupBy 似乎没有区别。

但是当我把Select-clause 改成这样的时候

var ciQueryNvarchar = this.Scope.Set<InfoEntity>().Where(ciPredicate).GroupBy(x => new { x.Source, x.InfoKey })
                .Select(group => new {
                    Group = group.Key,
                    MostRecentItem = group.OrderByDescending(x => x.InfoSeqNr).FirstOrDefault()
                }).ToList();

EF 在生成的 SQL 语句中不再使用 nvarchar(4000)。所以这可能是一种解决方法，但它并不漂亮......

更好的选择是完全重写查询，因为 LINQ GroupBy 和 SQL GROUP BY are different things。 LINQ 的 GroupBy 是某种排序 + 分桶操作，而 SQL 的 GROUP BY 还结合了聚合函数，我们在这种情况下没有。

因此，上面的查询可以重写为

var ciQueryNvarchar = this.Scope.Set<InfoEntity>()
    .Where(ciPredicate)
    .Select(x => new { x.Source, x.InfoKey })
    .Distinct()
    .Select(x => this.Scope.Set<InfoEntity>()
        .Where(ciPredicate)
        .Where(y => y.Source == x.Source && y.InfoKey == x.InfoKey)
        .OrderByDescending(y => y.InfoSeqNr)
        .FirstOrDefault()
    )
    .ToList();

比较查询计划时，初始查询和重写查询生成的 SQL 几乎相同，但有趣的部分在于可以解释类型更改为 nvarchar 的差异。

在 .NET 中，所有字符串都是 Unicode (nvarchar)。因此，如果生成的查询包含 SELECT @p__linq__0 AS [p__linq__0], @p__linq__1 AS [p__linq__1]，EF 的最佳猜测是使用 nvarchar 来匹配该列以匹配 .NET 的 unicode 字符串。

所以它可能毕竟不是一个错误？

另一种选择可能是使用纯 SQL（这也将使查询更具可读性），但这也可能不理想（鉴于重命名重构和数据库架构更改）。