Quelles sont les différences entre & et && dans EF Core

Selon la documentation Microsoft:

1.Le & Operator est pris en charge sous deux formes: un opérateur d'adresse unaire ou un opérateur logique binaire.

Opérateur d'adresse unaire:

L'opérateur unaire & renvoie l'adresse de son opérande. Pour plus d'informations, consultez Comment: obtenir l'adresse d'une variable . L'opérateur d'adresse de & requiert un contexte non sécurisé.

Opérateur AND logique au niveau du bit entier:

Pour les types entiers, le & calcule le bit logique AND de ses opérandes:

bool SecondOperand()
{
    Console.WriteLine("Second operand is evaluated.");
    return true;
}

bool a = false && SecondOperand(); // <-- second operand is not evaluated here
Console.WriteLine(a);
// Output:
// False

bool b = true && SecondOperand(); // <-- second operand is evaluated here
Console.WriteLine(b);
// Output:
// Second operand is evaluated.
// True

2. Le && Operator est l'opérateur AND logique conditionnel, également appelé l'opérateur ET logique "court-circuitant", calcule le ET logique de ses opérandes booléens. Le résultat de x && y est vrai si les deux x et y évaluent à true . Sinon, le résultat est false . Si le premier opérande est évalué à false , le deuxième opérande n'est pas évalué et le résultat de l'opération est false . L'exemple suivant illustre ce comportement:

uint a = 0b_1111_1000;
uint b = 0b_1001_1111;
uint c = a & b;
Console.WriteLine(Convert.ToString(c, toBase: 2));
// Output:
// 10011000

Maintenant, dans le cas du comportement EF / EF Core, @Ivan Stoev l'a beaucoup expliqué: Ici

mais qu'en est-il d'EF? Y a-t-il des différences entre & et && (idem pour | et ||)? en termes de performances!

Oui, c'est le cas.

Premièrement, EF Core utilise parfois évaluation du client , donc il ne peut pas être court-circuité.

Deuxièmement, même lors de l'utilisation de l'évaluation du serveur, EF Core les traduit différemment. Par exemple, voici la traduction pour SqlServer:

LINQ             SQL
==============   ============ 
expr1 && expr2   expr1 AND expr2
expr1 & expr2    (expr1 & expr2) = 1

La question de savoir si cela affecte les performances dépend de l'optimiseur de requêtes de base de données, mais le premier semble généralement meilleur. Et certains fournisseurs de bases de données qui n'ont pas de support natif pour le type bool peuvent générer une traduction assez inefficace ou même ne pas traduire les prédicats & / | .

Utilisez de préférence les opérateurs logiques && et || dans les requêtes LINQ.

J'ai décidé de faire un test:

SELECT [x].[CustomerId]
FROM [Customers] AS [x]
WHERE [x].[FirstName] IN (N'james', N'thomas')

vs

SELECT [x].[CustomerId]
FROM [Customers] AS [x]
WHERE (CASE
    WHEN [x].[FirstName] = N'james'
    THEN CAST(1 AS BIT) ELSE CAST(0 AS BIT)
END | CASE
    WHEN [x].[FirstName] = N'thomas'
    THEN CAST(1 AS BIT) ELSE CAST(0 AS BIT)
END) = 1

t1 a été exécuté comme:

var t2 = _db.Customers
.Where(x => x.FirstName == "james" || x.FirstName == "thomas")
.Select(x => x.CustomerId).ToList();

et t2 comme:

var t1 = _db.Customers
.Where(x => x.FirstName == "james" | x.FirstName == "thomas")
.Select(x=>x.CustomerId).ToList();

Les deux renvoient le même résultat. J'ai comparé leur plan d'exécution, pour exécuter t1 j'avais "Index Scan" tandis que pour exécuter t2 j'avais "Index Seek". Comme Justin l'a mentionné ( Plans SQL Server: différence entre l'analyse d'index / index Seek ) "Les recherches sont toujours meilleures que les analyses car elles sont plus efficaces dans la façon dont il recherche les données".

Donc, en utilisant | ou & non seulement cela peut conduire à une évaluation côté client, mais cela affectera également le SQL généré.

Merci à tous!