O uso inadequado de operadores lógicos levou a um desempenho de consulta ruim

Para descobrir se duas condições são realmente equivalentes, você pode tentar construir a tabela verdade para cada uma delas e ver se as duas tabelas são idênticas.

Aqui está como você pode construir as tabelas-verdade. Você tem duas variáveis, a, que podem ou não ser iguais a 1, e b, que podem ou não ser iguais a 0. Escreva e execute uma consulta como esta:

SELECT
  a
, b
, [a!=1 or (a=1 and b!=0)] = CASE WHEN a!=1 or (a=1 and b!=0) THEN 'True' ELSE 'False' END
, [not (a=1 and b=0)]      = CASE WHEN not (a=1 and b=0)      THEN 'True' ELSE 'False' END
FROM
  (
    VALUES
      (   1,    0)
    , (   1, 9999)
    , (9999,    0)
    , (9999, 9999)
  ) AS v (a, b)
;

Para cada variável, especifique o valor com o qual a variável é comparada, para que uma comparação correspondente seja verdadeira ou falsa (dependendo de ser =ou !=), e outro valor que produza o resultado oposto. O valor 9999 acima é apenas um valor arbitrário que significa "não 1" quando se trata de comparações com a, e "não 0" quando se trata de b. (Fui com algo completamente diferente de 1 ou 0 para não tornar a tabela resultante muito confusa.)

A consulta acima retornará a seguinte saída:

Como você pode ver, ambas as expressões fornecem resultados idênticos para valores de entrada idênticos.

Observe, no entanto, que a tabela acima contém apenas valores que fazem as comparações serem avaliadas como True ou False . É assim que as coisas normalmente são na álgebra booleana. No entanto, no mundo SQL, uma expressão booleana pode ser avaliada para um terceiro estado, Unknown , também conhecido como Null . Se afor anulável e for realmente um nulo, então a=1(ou a!=1para esse assunto) será avaliado como Unknown / Null . Se a nulidade precisar ser considerada, nossas tabelas-verdade devem incluir nulos como valores de entrada.

Aqui está uma versão modificada do script acima que inclui nulos para ambas as variáveis:

SELECT
  a
, b
, [a!=1 or (a=1 and b!=0)] = CASE
                               WHEN      a!=1 or (a=1 and b!=0)  THEN 'True'
                               WHEN NOT (a!=1 or (a=1 and b!=0)) THEN 'False'
                               ELSE 'Unknown'
                             END
, [not (a=1 and b=0)]      = CASE
                               WHEN      not (a=1 and b=0)       THEN 'True'
                               WHEN NOT (not (a=1 and b=0)     ) THEN 'False'
                               ELSE 'Unknown'
                             END
FROM
  (
    VALUES
      (   1,    0)
    , (   1, 9999)
    , (   1, NULL)
    , (9999,    0)
    , (9999, 9999)
    , (9999, NULL)
    , (NULL,    0)
    , (NULL, 9999)
    , (NULL, NULL)
  ) AS v (a, b)
;

E dá a seguinte saída:

Destacado acima está o cenário em que as duas condições não produzem os mesmos resultados, que é quando aé nulo e bé um valor não nulo que não é 0. Nesse caso, o resultado da primeira condição é desconhecido enquanto o da outra é verdadeiro.

Novamente, isso supõe que apode ser nulo e, sob essa suposição, suas duas expressões lógicas não são equivalentes. Mas se, por exemplo, só bpuder ser nulo e anão puder, você poderá ver na saída acima que os resultados nas linhas correspondentes são idênticos.

Você encontrará sua resposta, portanto, com base na nulidade das variáveis ​​envolvidas.

Alguns links para mais leitura:

• Tabela verdade
• Lógica de três valores

A condição not (a=1 and b=0)é igual a a!=1 or b!=0que obviamente não é igual aa!=0 or (a=1 and b!=0)

Por exemplo:

a = 0
b = 0

a!=0 or (a=1 and b!=0) => false or (false and false) => false

not (a=1 and b=0) => not (false and true) => true

Infelizmente, não acho que sua reescrita seja logicamente equivalente. Em seu primeiro predicado você tem o where a != 0 or ...que significa que quaisquer registros onde anão for igual 0serão retornados. Isso incluiria registros where a = 1 and b = 0(isso se deve especificamente ao uso de uma ORcláusula). Seu segundo predicado reescrito where not (a = 1 and b = 0)excluiria esse mesmo caso.

Mas você deve ser capaz de testar isso comparando as contagens de linhas de ambos os predicados, para verificar. Se necessário, você pode criar uma pequena tabela temporária com cada combinação de valores que está testando (por exemplo (a,b) = {(0,0), (0,1), (1,0), (1,1)}, ) e, em seguida, aplicar cada predicado para ver o resultado.

Uma dica que posso oferecer é que, às vezes, as ORcláusulas podem ser reescritas de forma mais eficiente UNIONentre os dois lados da cláusula em uma consulta separada. Por exemplo:

SELECT ...
FROM test
WHERE a!=0 

UNION

SELECT ...
FROM test
WHERE a=1 and b!=0

Dependendo de seus índices e predicados, isso pode permitir que um índice seja procurado com eficiência. Embora eu não tenha certeza se isso ajudaria no seu caso ao usar um operador de desigualdade como !=.

Mas fora isso, para sugestões de melhoria de desempenho, provavelmente precisaríamos ver seu plano de execução.