Fundamentos de expressões de tabela, Parte 8 – CTEs, considerações de otimização continuação

Múltiplas referências e não determinismo

-- Lote 1 DECLARE @i AS INT =1; WHILE @@ROWCOUNT =1 SELECT @i +=1 WHERE SYSDATETIME() =SYSDATETIME(); PRINT @i;GO -- Lote 2 DECLARE @i AS INT =1; WHILE @@ROWCOUNT =1 COM C AS ( SELECT SYSDATETIME() AS dt ) SELECT @i +=1 FROM C WHERE dt =dt; PRINT @i;GO -- Lote 3 DECLARE @i AS INT =1; WHILE @@ROWCOUNT =1 WITH C AS ( SELECT SYSDATETIME() AS dt ) SELECT @i +=1 WHERE (SELECT dt FROM C) =(SELECT dt FROM C); IMPRIMIR @i;GO

DBCC TRACEON(3604); -- saída direta para clientGO DBCC TRACEON(8605); -- mostra a árvore de consulta inicialGO

Funções de janela com ordem não determinística

USE TSQLV5; WITH C AS(SELECT *, ROW_NUMBER() OVER(ORDER BY orderdate) AS rownum FROM Sales.Orders)SELECT C1.orderid, C1.shipcountry, C2.orderidFROM C AS C1 INNER JOIN C AS C2 ON C1.rownum =C2. rownumWHERE C1.orderid <> C2.orderid;

orderid shipcountry orderid----------- --------------- -----------(0 linhas afetadas) 
 Eu obtive o plano mostrado na Figura 23 para esta consulta. 
 
 Figura 2:primeiro plano para consulta com duas referências CTE 
 
 O que é interessante notar aqui é que o otimizador optou por usar índices diferentes para lidar com as diferentes referências de CTE porque foi o que considerou ideal. Afinal, cada referência na consulta externa está relacionada a um subconjunto diferente das colunas CTE. Uma referência resultou em uma varredura direta ordenada do índice idx_nc_orderedate e a outra em uma varredura não ordenada do índice clusterizado seguida por uma operação de classificação por ordem crescente de data. Embora o índice idx_nc_orderedate seja explicitamente definido apenas na coluna orderdate como a chave, na prática ele é definido em (orderdate, orderid) como suas chaves, pois orderid é a chave do índice clusterizado e é incluída como a última chave em todos os índices não clusterizados. Assim, uma varredura ordenada do índice realmente emite as linhas ordenadas por orderdate, orderid. Quanto à verificação não ordenada do índice clusterizado, no nível do mecanismo de armazenamento, os dados são verificados em ordem de chave de índice (com base em orderid) para atender às expectativas de consistência mínima do nível de isolamento padrão lido confirmado. O operador Sort, portanto, ingere os dados ordenados por orderid, ordena as linhas por orderdate e, na prática, acaba emitindo as linhas ordenadas por orderdate, orderid. 
 
 Novamente, em teoria, não há garantia de que as duas referências sempre representarão o mesmo conjunto de resultados, mesmo que os dados subjacentes não sejam alterados. Uma maneira simples de demonstrar isso é organizar dois índices ótimos diferentes para as duas referências, mas ter um ordenar os dados por orderdate ASC, orderid ASC e o outro ordenar os dados por orderdate DESC, orderid ASC (ou exatamente o oposto). Já temos o antigo índice em vigor. Aqui está o código para criar o último:
 
CREATE INDEX idx_nc_odD_oid_I_sc ON Sales.Orders(orderdate DESC, orderid) INCLUDE(shipcountry);
 
 Execute o código uma segunda vez depois de criar o índice:
 
WITH C AS( SELECT *, ROW_NUMBER() OVER(ORDER BY orderdate) AS rownum FROM Sales.Orders)SELECT C1.orderid, C1.shipcountry, C2.orderidFROM C AS C1 INNER JOIN C AS C2 ON C1.rownum =C2.rownumWHERE C1.orderid <> C2.orderid;
 
 Eu obtive a seguinte saída ao executar este código depois de criar o novo índice:
 
orderid shipcountry orderid---------- --------------- -----------10251 França 1025010250 Brasil 1025110261 Brasil 1026010260 Alemanha 1026110271 EUA 10270...11070 Alemanha 1107311077 EUA 1107411076 França 1107511075 Suíça 1107611074 Dinamarca 11077(546 linhas afetadas)
 
 Ops. 
 
 Examine o plano de consulta para esta execução, conforme mostrado na Figura 3:
 
 Figura 3:segundo plano para consulta com duas referências CTE 
 
 Observe que a ramificação superior do plano varre o índice idx_nc_orderdate de forma ordenada, fazendo com que o operador Sequence Project, que calcula os números das linhas, ingira os dados na prática ordenados por orderdate ASC, orderid ASC. A ramificação inferior do plano varre o novo índice idx_nc_odD_oid_I_sc de forma ordenada para trás, fazendo com que o operador Sequence Project ingira os dados na prática ordenados por orderdate ASC, orderid DESC. Isso resulta em um arranjo diferente de números de linha para as duas referências CTE sempre que houver mais de uma ocorrência do mesmo valor orderdate. Consequentemente, a consulta gera um conjunto de resultados não vazio. 
 
 Se você quiser evitar esses bugs, uma opção óbvia é persistir o resultado da consulta interna em um objeto temporário como uma tabela temporária ou variável de tabela. No entanto, se você tiver uma situação em que prefere usar CTEs, uma solução simples é usar a ordem total na função de janela adicionando um desempate. Em outras palavras, certifique-se de ordenar por uma combinação de expressões que identifica exclusivamente uma linha. No nosso caso, você pode simplesmente adicionar orderid explicitamente como um desempate, assim:
 
WITH C AS( SELECT *, ROW_NUMBER() OVER(ORDER BY orderdate, orderid) AS rownum FROM Sales.Orders)SELECT C1.orderid, C1.shipcountry, C2.orderidFROM C AS C1 INNER JOIN C AS C2 ON C1 .rownum =C2.rownumWHERE C1.orderid <> C2.orderid;
 
 Você obtém um conjunto de resultados vazio conforme o esperado:
 
orderid shipcountry orderid----------- --------------- -----------(0 linhas afetadas) 
 Sem adicionar mais índices, você obtém o plano mostrado na Figura 4:
 
 Figura 4:Terceiro plano para consulta com duas referências CTE 
 
 A ramificação superior do plano é a mesma do plano anterior mostrado na Figura 3. A ramificação inferior é um pouco diferente. O novo índice criado anteriormente não é realmente ideal para a nova consulta no sentido de que não possui os dados ordenados como a função ROW_NUMBER precisa (orderdate, orderid). Ainda é o índice de cobertura mais estreito que o otimizador pode encontrar para sua respectiva referência CTE, então é selecionado; no entanto, ele é escaneado no modo Ordered:False. Um operador Sort explícito então classifica os dados por orderdate, orderid como a computação ROW_NUMBER precisa. Obviamente, você pode alterar a definição do índice para que orderdate e orderid usem a mesma direção e, dessa forma, a classificação explícita será eliminada do plano. O ponto principal, porém, é que, ao usar o pedido total, você evita problemas devido a esse bug específico. 
 
 Quando terminar, execute o seguinte código para limpeza:
 
DROP INDEX IF EXISTS idx_nc_odD_oid_I_sc ON Sales.Orders;
 
Conclusão
 
 É importante entender que várias referências ao mesmo CTE de uma consulta externa resultam em avaliações separadas da consulta interna do CTE. Tenha especial cuidado com cálculos não determinísticos, pois as diferentes avaliações podem resultar em valores diferentes. 
 
 Ao usar funções de janela como ROW_NUMBER e agregações com um quadro, certifique-se de usar a ordem total para evitar obter resultados diferentes para a mesma linha nas diferentes referências de CTE.