O problema me deixou louco por alguns dias, posso ter encontrado minha resposta, mas preciso de uma confirmação e verificar uma eventual solução fácil.
Quando um procedimento armazenado usa algumas funções definidas pelo usuário, os planos UDF são mesclados no plano principal e tudo é otimizado ou eles são chamados diretamente todas as vezes?
E suponha que isso não aconteça, existe uma maneira de forçar o SQL Server a fazer isso para um SP específico?
Encontrei essa condição ao otimizar um SP, há uma parte do plano de execução que realmente não entendo: o SQL Server faz uma varredura de índice e filtra os resultados. Qual é a razão para o SQL Server fazer isso, em vez de fazer tudo na varredura de índice ?
Por exemplo:
O índice já contém todos os campos usados pelo WHERE . Expandi a operação Index Scan , e ela executa parte do where com alguns parâmetros envolvidos (totalmente esperado). Em seguida, expandi e inspecionei a operação Filter , e o que ela faz é aplicar alguma outra filtragem em alguns campos de data e hora já avaliados pelo Index Scan , além de algumas outras condições em alguns outros parâmetros do SP.
O que está acontecendo aqui? Obviamente, não me importo com minha consulta específica, esse não é o ponto, estou tentando entender quais condições podem fazer com que isso aconteça.
Criei uma visão materializada no SQL Server, mas ao selecionar a partir dela obtenho os mesmos desempenhos e o mesmo plano de execução do que quando seleciono da mesma consulta não "materializada".
A visão é simples:
CREATE VIEW TestView WITH SCHEMABINDING
AS
SELECT TAB_A.C1, TAB_A.C2, TAB_A.C3
FROM TAB1
INNER JOIN TAB2 ON TAB1.C2 = TAB2.C2
INNER JOIN TAB3 ON TAB2.C1 = TAB3.C1;
CREATE UNIQUE CLUSTERED INDEX IX_TestView
ON TestView(C1, C2, C3);
Agora, quando eu faço algo como
SELECT C1 FROM TestView
Eu esperaria ver no plano apenas um acesso à visão e nada mais, em vez disso, ele acessa as tabelas subjacentes como se a visão nem existisse. Eu recebo exatamente o mesmo plano e o mesmo tempo de execução também.
O que estou fazendo errado? Se o SQL Server não puder "materializar" a exibição, esperaria pelo menos obter um erro ao criá-la.
Ok, não consegui encontrar um título melhor, para ser honesto.
Recentemente, cheguei a um novo local de trabalho e me pediram para ajudar com o banco de dados. Eu queria tentar explicar um conceito, mas não tenho certeza de como expressar isso na melhor das hipóteses, e talvez esse conceito já tenha uma explicação melhor e um nome também. Eu não me classifico como um especialista em DB, então gostaria de apresentar a eles algo mais oficial do que meu próprio ponto de vista, não importa quantos bons DBs eu tenha projetado em minha vida.
Uma das coisas que achei mais divertidas (mas não no bom sentido) é que eles parecem seguir o design do db de acordo com a lógica do problema e não de acordo com "este é um banco de dados, deve conter dados", então por exemplo para saber se um elemento está em uma determinada categoria, a consulta fica assim (em pseudocódigo):
SELECT Column1, Column2...ColumnN
FROM Invoices [LIST OF JOIN]
WHERE
Invoces.Field1 IN
(TableA WHERE TableA.Field NOT IN
(TableB WHERE TableB.Field IN ((TableC WHERE) OR (TableD WHERE)))
OR Invoces.Field1 NOT IN
(TableB WHERE TableB.Field IN ((TableC WHERE) AND (TableD WHERE))
OR TableB.Field IN
(TableC WHERE TableC.Field IN (TableC WHERE))
OR TableB.Field NOT IN
(TableC WHERE TableC.Field NOT IN (TableD WHERE))
e assim por diante para outras vinte condições. Não, não estou brincando.
Isso acontece porque ao invés de dizer "esta é uma fatura e sua categoria é um atributo da própria fatura", eles vão até o fim com coisas como "a fatura foi inserida por aquele usuário, naquele dia, e ele poderia ter inserido em um determinado departamento ou em nenhum, e no caso do departamento, então esse departamento pode ser parte de uma certa estrutura..." e assim por diante. Não é nem uma questão de integridade referencial, não há FKs neste caso...
Outro exemplo prático é a data da última edição de um documento: ao invés de ser armazenado como um atributo, é calculado por uma função que segue algo assim:
se esse documento estiver relacionado a outro, então se o outro for deste tipo, então se o primeiro documento estiver relacionado a este outro documento também, então a data da última edição é a data em que o administrador imprimiu o calendário diário de compromissos". .
claramente com um monte de outros para cada se, também. E, não é porque há algum tipo de dependência, é apenas porque muitas coisas são armazenadas para refletir sua lógica.
De certa forma, ficaria tentado a dizer "escreva uma vez, leia muitos", com o significado de "escreva esse atributo uma vez e depois leia de graça quantas vezes precisar", porque temos uma baixa frequência de gravações e uma frequência muito alta de leituras, e claramente todas as leituras devem sempre recalcular tudo. Mas tenho a sensação de que deve haver algum princípio que diz que você deve projetar bancos de dados para armazenar dados...
Já procurei em todos os lugares mas não consegui encontrar nada a respeito, parece que todo mundo está preocupado apenas com WHERE e CASE. (e não tenho um SQL Server disponível para verificar por mim mesmo)
Então, uma pergunta simples: o JOIN de curto-circuito do SQL Server é baseado na condição JOIN? Se eu escrever:
TableA LEFT OUTER JOIN TableB ON 1=0 AND TableA.ID = TableB.A_ID
O SQL Server ignorará a junção?
Editar
Ok, alguém apontou corretamente que isso é resolvido em tempo de compilação, então é melhor eu expandir a questão.
O acima foi apenas um exemplo, mas acabou sendo ruim. O que eu queria saber é se o SQL Server causa um curto-circuito em um JOIN quando essa condição acontece em tempo de execução, como consequência de um @parameter passado para um procedimento armazenado.
Estou perguntando porque tenho certeza de ter usado algo assim nos anos, mas queria ter 100% de certeza antes de falar sobre isso com alguns colegas. Então, o SQL Server fará um curto-circuito nisso, então:
TableA LEFT OUTER JOIN TableB ON @parameter IS NOT NULL AND TableA.ID = TableB.A_ID
se estiver dentro de um SP e for chamado com @parameter definido como NULL? Fará alguma diferença se o procedimento de armazenamento for COM RECOMPILAR?