Fundamentos de expressões de tabela, Parte 3 – Tabelas derivadas, considerações de otimização

• Persistência: Uma tabela derivada é persistida em algum lugar? Ele é persistido no disco e como o SQL Server lida com a memória para ele?
• Projeção de coluna: Como a correspondência de índice funciona com tabelas derivadas? Por exemplo, se uma tabela derivada projeta um determinado subconjunto de colunas de alguma tabela subjacente e a consulta externa projeta um subconjunto das colunas da tabela derivada, o SQL Server é inteligente o suficiente para descobrir a indexação ideal com base no subconjunto final de colunas que é realmente necessário? E as permissões; o usuário precisa de permissões para todas as colunas que são referenciadas nas consultas internas ou apenas para as últimas que são realmente necessárias?
• Várias referências a aliases de coluna: Se a tabela derivada tiver uma coluna de resultado baseada em uma computação não determinística, por exemplo, uma chamada para a função SYSDATETIME, e a consulta externa tiver várias referências a essa coluna, a computação será feita apenas uma vez ou separadamente para cada referência externa ?
• Desaninhamento/substituição/inline: O SQL Server desaninha ou inline a consulta de tabela derivada? Ou seja, o SQL Server executa um processo de substituição pelo qual converte o código aninhado original em uma consulta que vai diretamente nas tabelas base? E em caso afirmativo, existe uma maneira de instruir o SQL Server para evitar esse processo de desaninhamento?

Persistência

Projeção de coluna e uma palavra em SELECT *

SELECT x, zFROM R1;

SELECT DISTINCT x, zFROM R1;

USE TSQLV5;GO SELECT custid, cidade, 1/0 AS div0errorFROM Sales.Customers;

SELECT custid, cityFROM ( SELECT custid, city, 1/0 AS div0error FROM Sales.Customers ) AS D;

SELECT custid, cityFROM Sales.Customers;

SELECT countryFROM ( SELECT * FROM Sales.Customers GROUP BY country ) AS D;

CREATE INDEX idx_custid_odD_oidD ON Sales.Orders(custid, orderdate DESC, orderid DESC);

SELECT custid, orderdate, orderid, rownumFROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY custid ORDER BY orderdate DESC, orderid DESC) AS rownum FROM Sales.Orders ) AS DWHERE rownum <=3;

CRIA USUÁRIO user1 SEM LOGIN; GRANT SHOWPLAN TO user1; GRANT SELECT ON Sales.Customers TO user1; GRANT SELECT ON Sales.Orders(custid, orderdate, orderid) TO user1;

EXECUTAR COMO USUÁRIO ='usuário1';

SELECT * FROM Sales.Orders;

SELECT custid, orderdate, orderid, rownumFROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY custid ORDER BY orderdate DESC, orderid DESC) AS rownum FROM Sales.Orders ) AS DWHERE rownum <=3;

SELECT custid, orderdate, orderid, rownumFROM ( SELECT custid, orderdate, orderid, ROW_NUMBER() OVER(PARTITION BY custid ORDER BY orderdate DESC, orderid DESC) AS rownum FROM Sales.Orders ) AS DWHERE rownum <=3; 
 Desta vez, a consulta é executada sem erros. 
 
 Outra variação que exige que o usuário tenha permissões apenas nas colunas relevantes é ser explícito sobre os nomes das colunas na lista SELECT da consulta interna e usar SELECT * na consulta externa, assim:
 
SELECT *FROM ( SELECT custid, orderdate, orderid, ROW_NUMBER() OVER(PARTITION BY custid ORDER BY orderdate DESC, orderid DESC) AS rownum FROM Sales.Orders ) AS DWHERE rownum <=3;
 
 Essa consulta também é executada sem erros. No entanto, vejo esta versão como propensa a bugs, caso mais tarde algumas alterações sejam feitas em algum nível interno de aninhamento. Como mencionado anteriormente, para mim, a melhor prática é ser explícito sobre a lista de colunas na consulta externa. Portanto, desde que você não tenha nenhuma preocupação com a falta de permissão em algumas das colunas, me sinto confortável com SELECT * em consultas internas, mas uma lista de colunas explícita na consulta externa. Se a aplicação de permissões de coluna específicas for uma prática comum na empresa, é melhor simplesmente ser explícito sobre os nomes das colunas em todos os níveis de aninhamento. Lembre-se de que ser explícito sobre os nomes das colunas em todos os níveis de aninhamento é realmente obrigatório se sua consulta for usada em um objeto vinculado a esquema, pois a vinculação de esquema não permite o uso de SELECT * em qualquer lugar da consulta. 
 
 Neste ponto, execute o seguinte código para remover o índice que você criou anteriormente em Sales.Orders:
 
DROP INDEX IF EXISTS idx_custid_odD_oidD ON Sales.Orders;
 
 Há outro caso com um dilema semelhante em relação à legitimidade do uso de SELECT *; na consulta interna do predicado EXISTS. 
 
 Considere a seguinte consulta (vamos chamá-la de Consulta 2):
 
SELECT custidFROM Sales.Customers AS CWHERE EXISTS (SELECT * FROM Sales.Orders AS O WHERE O.custid =C.custid);
 
 O plano para esta consulta é mostrado na Figura 2. 
 
 Figura 2:plano para consulta 2 
 
 Ao aplicar a correspondência de índice, o otimizador percebeu que o índice idx_nc_custid é um índice de cobertura em Sales.Orders, pois contém a coluna custid — a única coluna realmente relevante nessa consulta. Isso apesar do fato de que este índice não contém nenhuma outra coluna além de custid, e que a consulta interna no predicado EXISTS diz SELECT *. Até agora, o comportamento parece semelhante ao uso de SELECT * em tabelas derivadas. 
 
 A diferença dessa consulta é que ela é executada sem erros, apesar de user1 não ter permissões em algumas das colunas de Sales.Orders. Há um argumento para justificar não exigir permissões em todas as colunas aqui. Afinal, o predicado EXISTS só precisa verificar a existência de linhas correspondentes, então a lista SELECT da consulta interna é realmente sem sentido. Provavelmente teria sido melhor se o SQL não exigisse uma lista SELECT nesse caso, mas esse navio já partiu. A boa notícia é que a lista SELECT é efetivamente ignorada - tanto em termos de correspondência de índice quanto em termos de permissões necessárias. 
 
 Também parece que há outra diferença entre tabelas derivadas e EXISTS ao usar SELECT * na consulta interna. Lembre-se desta consulta no início do artigo:
 
SELECT countryFROM ( SELECT * FROM Sales.Customers GROUP BY country ) AS D;
 
 Se você se lembra, esse código gerou um erro, pois a consulta interna é inválida. 
 
 Tente a mesma consulta interna, só que desta vez no predicado EXISTS (chamaremos isso de Declaração 3):
 
IF EXISTS ( SELECT * FROM Sales.Customers GROUP BY country ) PRINT 'Isto funciona! Obrigado Dmitri Korotkevitch pela dica!';
 
 Estranhamente, o SQL Server considera esse código válido e é executado com êxito. O plano para este código é mostrado na Figura 3. 
 
 Figura 3:plano para a declaração 3 
 
 Este plano é idêntico ao plano que você obteria se a consulta interna fosse apenas SELECT * FROM Sales.Customers (sem o GROUP BY). Afinal, você está verificando a existência de grupos e, se houver linhas, naturalmente haverá grupos. De qualquer forma, acho que o fato de o SQL Server considerar essa consulta como válida é um bug. Certamente, o código SQL deve ser válido! Mas posso ver por que alguns podem argumentar que a lista SELECT na consulta EXISTS deve ser ignorada. De qualquer forma, o plano usa uma semijunção esquerda testada, que não precisa retornar nenhuma coluna, em vez disso, apenas sonda uma tabela para verificar a existência de quaisquer linhas. O índice em Clientes pode ser qualquer índice. 
 
 Neste ponto, você pode executar o seguinte código para parar de representar o usuário1 e eliminá-lo:
 
REVERTER; DROP USER SE EXISTE user1;
 
 Voltando ao fato de que acho uma prática conveniente usar SELECT * em níveis internos de aninhamento, quanto mais níveis você tiver, mais essa prática encurtará e simplificará seu código. Aqui está um exemplo com dois níveis de aninhamento:
 
SELECT orderid, orderyear, custid, empid, shipperidFROM ( SELECT *, DATEFROMPARTS(orderyear, 12, 31) AS endofyear FROM ( SELECT *, YEAR(orderdate) AS orderyear FROM Sales.Orders ) AS D1 ) AS D2WHERE orderdate =fim de ano;
 
 Há casos em que esta prática não pode ser utilizada. Por exemplo, quando a consulta interna une tabelas com nomes de colunas comuns, como no exemplo a seguir:
 
SELECT custid, nome da empresa, orderdate, orderid, rownumFROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY C.custid ORDER BY O.orderdate DESC, O.orderid DESC) AS rownum FROM Sales.Customers AS C LEFT OUTER JOIN Vendas.Pedidos AS O ON C.custid =O.custid ) AS DWHERE rownum <=3;
 
 Tanto Sales.Customers quanto Sales.Orders têm uma coluna chamada custid. Você está usando uma expressão de tabela baseada em uma junção entre as duas tabelas para definir a tabela derivada D. Lembre-se de que o cabeçalho de uma tabela é um conjunto de colunas e, como conjunto, você não pode ter nomes de coluna duplicados. Portanto, essa consulta falha com o seguinte erro:
 Msg 8156, Level 16, State 1
A coluna 'custid' foi especificada várias vezes para 'D'. 
 Aqui, você precisa ser explícito sobre os nomes das colunas na consulta interna e certificar-se de retornar custid de apenas uma das tabelas ou atribuir nomes de coluna exclusivos às colunas de resultado caso deseje retornar ambas. Mais frequentemente, você usaria a abordagem anterior, assim:
 
SELECT custid, companyname, orderdate, orderid, rownumFROM ( SELECT C.custid, C.companyname, O.orderdate, O.orderid, ROW_NUMBER() OVER(PARTITION BY C.custid ORDER BY O.orderdate DESC, O. orderid DESC) AS rownum FROM Sales.Customers AS C LEFT OUTER JOIN Sales.Orders AS O ON C.custid =O.custid ) AS DWHERE rownum <=3;
 
 Novamente, você pode ser explícito com os nomes das colunas na consulta interna e usar SELECT * na consulta externa, assim:
 
SELECT *FROM ( SELECT C.custid, C.companyname, O.orderid, O.orderid, ROW_NUMBER() OVER(PARTITION BY C.custid ORDER BY O.orderdate DESC, O.orderid DESC) AS rownum FROM Sales .Clientes AS C LEFT OUTER JOIN Vendas.Pedidos AS O ON C.custid =O.custid ) AS DWHERE rownum <=3;
 
 Mas, como mencionei anteriormente, considero uma prática ruim não ser explícito sobre os nomes das colunas na consulta externa. 
 
Várias referências a aliases de coluna
 
 Vamos prosseguir para o próximo item – várias referências a colunas de tabelas derivadas. Se a tabela derivada tiver uma coluna de resultado baseada em uma computação não determinística e a consulta externa tiver várias referências a essa coluna, a computação será avaliada apenas uma vez ou separadamente para cada referência? 
 
 Vamos começar com o fato de que várias referências à mesma função não determinística em uma consulta devem ser avaliadas independentemente. Considere a seguinte consulta como um exemplo:
 
SELECT NEWID() AS mynewid1, NEWID() AS mynewid2;
 
 Este código gera a seguinte saída mostrando dois GUIDs diferentes:
 
mynewid1 mynewid2--------------------- --------- ---------------------------7BF389EC-082F-44DA-B98A-DB85CD095506 EA1EFF65-B2E4-4060-9592-7116F674D406
 
 Por outro lado, se você tiver uma tabela derivada com uma coluna baseada em uma computação não determinística e a consulta externa tiver várias referências a essa coluna, a computação deverá ser avaliada apenas uma vez. Considere a seguinte consulta (chamaremos isso de Consulta 4):
 
SELECT mynewid AS mynewid1, mynewid AS mynewid2FROM ( SELECT NEWID() AS mynewid ) AS D;
 
 O plano para esta consulta é mostrado na Figura 4. 
 
 Figura 4:planejar a consulta 4 
 
 Observe que há apenas uma invocação da função NEWID no plano. Assim, a saída mostra o mesmo GUID duas vezes:
 
mynewid1 mynewid2--------------------- --------- ---------------------------296A80C9-260A-47F9-9EB1-C2D0C401E74A 296A80C9-260A-47F9-9EB1-C2D0C401E74A
 
 Portanto, as duas consultas acima não são logicamente equivalentes e há casos em que a inserção/substituição não ocorre. 
 
 Com algumas funções não determinísticas, é um pouco mais complicado demonstrar que várias invocações em uma consulta são tratadas separadamente. Tome a função SYSDATETIME como exemplo. Tem precisão de 100 nanossegundos. Quais são as chances de que uma consulta como a seguinte mostre realmente dois valores diferentes? 
 
SELECT SYSDATETIME() AS mydt1, SYSDATETIME() AS mydt2;
 
 Se você estiver entediado, pode pressionar F5 repetidamente até que isso aconteça. Se você tiver coisas mais importantes para fazer com seu tempo, talvez prefira executar um loop, assim:
 
DECLARE @i AS INT =1; WHILE EXISTS( SELECT * FROM ( SELECT SYSDATETIME() AS mydt1, SYSDATETIME() AS mydt2 ) AS D WHERE mydt1 =mydt2 ) SET @i +=1; IMPRIMIR @i;
 
 Por exemplo, quando executei este código, obtive 1971. 
 
 Se você quiser certificar-se de que a função não determinística seja invocada apenas uma vez e contar com o mesmo valor em várias referências de consulta, certifique-se de definir uma expressão de tabela com uma coluna baseada na invocação da função e ter várias referências a essa coluna da consulta externa, assim (chamaremos essa Consulta 5):
 
SELECT mydt AS mydt1, mydt AS mydt1FROM ( SELECT SYSDATETIME() AS mydt ) AS D;
 
 O plano para esta consulta é mostrado na Figura 5. 
 
 Figura 5:planejar a consulta 5 
 
 Observe no plano que a função é chamada apenas uma vez. 
 
 Agora, este pode ser um exercício muito interessante em pacientes para bater F5 repetidamente até obter dois valores diferentes. A boa notícia é que uma vacina para o COVID-19 será encontrada mais cedo. 
 
 Você pode, é claro, tentar executar um teste com um loop:
 
DECLARE @i AS INT =1; WHILE EXISTS ( SELECT * FROM (SELECT mydt AS mydt1, mydt AS mydt2 FROM ( SELECT SYSDATETIME() AS mydt ) AS D1) AS D2 WHERE mydt1 =mydt2 ) SET @i +=1; PRINT @i;
 
 You can let it run as long as you feel that it’s reasonable to wait, but of course it won’t stop on its own. 
 
 Understanding this, you will know to avoid writing code such as the following:
 
SELECT CASE WHEN RAND() <0.5 THEN STR(RAND(), 5, 3) + ' is less than half.' ELSE STR(RAND(), 5, 3) + ' is at least half.' END;
 
 Because occasionally, the output will not seem to make sense, e.g., 
 
0.550 is less than half.
 For more on evaluation within a CASE expression, see the section "Expressions can be evaluated more than once" in Aaron Bertrand's post, "Dirty Secrets of the CASE Expression." 
 Instead, you should either store the function’s result in a variable and then work with the variable or, if it needs to be part of a query, you can always work with a derived table, like so:
 
SELECT CASE WHEN rnd <0.5 THEN STR(rnd, 5, 3) + ' is less than half.' ELSE STR(rnd, 5, 3) + ' is at least half.' ENDFROM ( SELECT RAND() AS rnd ) AS D;
 
Resumo
 
 In this article I covered some aspects of the physical processing of derived tables. 
 
 When the outer query projects only a subset of the columns of a derived table, SQL Server is able to apply efficient index matching based on the columns in the outermost SELECT list, or that play some other meaningful role in the query, such as filtering, grouping, ordering, and so on. From this perspective, if for brevity you prefer to use SELECT * in inner levels of nesting, this will not negatively affect index matching. However, the executing user (or the user whose effective permissions are evaluated), needs permissions to all columns that are referenced in inner levels of nesting, even those that eventually are not really relevant. An exception to this rule is the SELECT list of the inner query in an EXISTS predicate, which is effectively ignored. 
 
 When you have multiple references to a nondeterministic function in a query, the different references are evaluated independently. Conversely, if you encapsulate a nondeterministic function call in a result column of a derived table, and refer to that column multiple times from the outer query, all references will rely on the same function invocation and get the same values.