查詢 Null 語意

簡介

當執行比較時，SQL 資料庫會以 3 值邏輯 （ true 、 false 、 null ） 運作，而不是 C# 的布林邏輯。 將 LINQ 查詢轉譯為 SQL 時，EF Core 會嘗試藉由引進查詢某些元素的額外 Null 檢查來補償差異。 為了說明這一點，讓我們定義下列實體：

public class NullSemanticsEntity
{
    public int Id { get; set; }
    public int Int { get; set; }
    public int? NullableInt { get; set; }
    public string String1 { get; set; }
    public string String2 { get; set; }
}

併發出數個查詢：

var query1 = context.Entities.Where(e => e.Id == e.Int);
var query2 = context.Entities.Where(e => e.Id == e.NullableInt);
var query3 = context.Entities.Where(e => e.Id != e.NullableInt);
var query4 = context.Entities.Where(e => e.String1 == e.String2);
var query5 = context.Entities.Where(e => e.String1 != e.String2);

前兩個查詢會產生簡單的比較。 在第一個查詢中，這兩個數據行不可為 Null，因此不需要 Null 檢查。 在第二個查詢中， NullableInt 可以包含 null ，但 Id 不可為 Null;相較于 null 結果的非 Null 產生 null ，作業會篩選掉 WHERE 。 因此，也不需要額外的條款。

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE [e].[Id] = [e].[Int]

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE [e].[Id] = [e].[NullableInt]

第三個查詢引進 Null 檢查。 null當 NullableInt 是比較 Id <> NullableInt 會產生 null 時，這會依 WHERE 作業篩選掉。 不過，從布林邏輯的觀點來看，這個案例應該傳回做為結果的一部分。 因此，EF Core 會新增必要的檢查，以確保這一點。

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE ([e].[Id] <> [e].[NullableInt]) OR [e].[NullableInt] IS NULL

當這兩個數據行都可為 Null 時，查詢四和五會顯示模式。 值得注意的是， <> 作業會產生比 == 作業更複雜（且可能較慢）的查詢。

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE ([e].[String1] = [e].[String2]) OR ([e].[String1] IS NULL AND [e].[String2] IS NULL)

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE (([e].[String1] <> [e].[String2]) OR ([e].[String1] IS NULL OR [e].[String2] IS NULL)) AND ([e].[String1] IS NOT NULL OR [e].[String2] IS NOT NULL)

在函式中處理可為 Null 的值

SQL 中的許多函式只有在部分引數為 null 時，才能傳回 null 結果。 EF Core 會利用這項功能來產生更有效率的查詢。 下列查詢說明優化：

var query = context.Entities.Where(e => e.String1.Substring(0, e.String2.Length) == null);

產生的 SQL 如下所示（我們不需要評估函 SUBSTRING 式，因為它只有在其中一個引數為 null 時才會是 null。

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE [e].[String1] IS NULL OR [e].[String2] IS NULL

優化也可用於使用者定義函式。 如需詳細資訊，請參閱 使用者定義函數對應 頁面。

撰寫高效能查詢

• 比較不可為 Null 的資料行比比較可為 Null 的資料行更簡單且更快。 請考慮盡可能將資料行標示為不可為 Null。

• 檢查是否相等 == （）比檢查不相等 != 更為簡單且更快，因為查詢不需要區分 null 和 false 結果。 盡可能使用相等比較。 不過，只是否定 == 比較實際上與 != 相同，因此不會產生效能改善。

• 在某些情況下，可以藉由明確篩選 null 出資料行中的值來簡化複雜的比較，例如，當沒有任何 null 值存在，或這些值與結果無關時。 請考慮下列範例：

var query1 = context.Entities.Where(e => e.String1 != e.String2 || e.String1.Length == e.String2.Length);
var query2 = context.Entities.Where(
    e => e.String1 != null && e.String2 != null && (e.String1 != e.String2 || e.String1.Length == e.String2.Length));

這些查詢會產生下列 SQL：

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE ((([e].[String1] <> [e].[String2]) OR ([e].[String1] IS NULL OR [e].[String2] IS NULL)) AND ([e].[String1] IS NOT NULL OR [e].[String2] IS NOT NULL)) OR ((CAST(LEN([e].[String1]) AS int) = CAST(LEN([e].[String2]) AS int)) OR ([e].[String1] IS NULL AND [e].[String2] IS NULL))

SELECT [e].[Id], [e].[Int], [e].[NullableInt], [e].[String1], [e].[String2]
FROM [Entities] AS [e]
WHERE ([e].[String1] IS NOT NULL AND [e].[String2] IS NOT NULL) AND (([e].[String1] <> [e].[String2]) OR (CAST(LEN([e].[String1]) AS int) = CAST(LEN([e].[String2]) AS int)))

在第二個查詢中， null 結果會明確地從 String1 資料行篩選掉。 EF Core 可以在比較期間安全地將資料 String1 行視為不可為 Null，因而產生更簡單的查詢。

使用關聯式 Null 語意

可以停用 Null 比較補償，並直接使用關聯式 Null 語意。 這可以透過在 方法內的選項產生器上 OnConfiguring 呼叫 UseRelationalNulls(true) 方法來完成：

new SqlServerDbContextOptionsBuilder(optionsBuilder).UseRelationalNulls();

警告

使用關聯式 Null 語意時，您的 LINQ 查詢不再具有與 C# 相同的意義，而且可能會產生與預期不同的結果。 使用此模式時請小心。