Edit: +1 funciona nessa situação, porque FILE_NUMBER
é uma versão de string preenchida com zero de um número inteiro. Uma solução melhor aqui para seqüências de caracteres é anexar ''
(a sequência vazia), pois a adição de um valor pode afetar a ordem ou os números adicionarem algo que é uma constante, mas contém uma função não determinística, como sign(rand()+1)
. A idéia de 'quebrar o tipo' ainda é válida aqui, mas meu método não era ideal.
+1
Não, não quero dizer que estou de acordo com nada, quero dizer isso como uma solução. Se você alterar sua consulta para ORDER BY cj.FILE_NUMBER + 1
, o TOP 1
comportamento será diferente.
Veja que, com a pequena meta de linha em vigor para uma consulta ordenada, o sistema tentará consumir os dados em ordem, para evitar ter um operador de classificação. Ele também evitará criar uma tabela de hash, imaginando que provavelmente não precisa fazer muito trabalho para encontrar a primeira linha. No seu caso, isso está errado - pela espessura dessas setas, parece que é preciso consumir muitos dados para encontrar uma única correspondência.
A espessura dessas setas sugere que a DOCUMENT_QUEUE
tabela (DQ) é muito menor que a CORRESPONDENCE_JOURNAL
tabela (CJ). E que o melhor plano seria realmente verificar as linhas DQ até que uma linha CJ seja encontrada. Na verdade, é isso que o Query Optimizer (QO) faria se não tivesse esse problema ORDER BY
lá dentro, muito bem suportado por um índice de cobertura no CJ.
Portanto, se você descartou ORDER BY
completamente, espero que você obtenha um plano que envolva um loop aninhado, iterando pelas linhas no DQ, procurando no CJ para garantir que a linha exista. E com TOP 1
isso isso parava depois que uma única linha era puxada.
Mas se você realmente precisar da primeira linha em FILE_NUMBER
ordem, poderá enganar o sistema para ignorar o índice que parece (incorretamente) ser útil, fazendo ORDER BY CJ.FILE_NUMBER+1
- o que sabemos que manterá a mesma ordem de antes, mas principalmente o QO não. O QO se concentrará em obter o conjunto completo, para que um operador Top N Sort possa ser satisfeito. Esse método deve produzir um plano que contenha um operador Compute Scalar para calcular o valor do pedido e um operador Top N Sort para obter a primeira linha. Mas, à direita, você deve ver um Nested Loop agradável, fazendo muitas pesquisas no CJ. E melhor desempenho do que executar uma grande tabela de linhas que não corresponde a nada no DQ.
O Hash Match não é necessariamente horrível, mas se o conjunto de linhas que você está retornando do DQ é muito menor que o CJ (como eu esperava que fosse), o Hash Match analisará muito mais o CJ do que precisa.
Nota: usei +1 em vez de +0 porque é provável que o otimizador de consultas reconheça que +0 não altera nada. Obviamente, o mesmo pode ser aplicado ao +1, se não agora, em algum momento no futuro.
DOCUMENT_ID
relacionamento entre as duas tabelas (ou cada registroCORRESPONDENCE_JOURNAL
possui um registro correspondenteDOCUMENT_QUEUE
)?