Select at.customerid, at.tdate from salestransaction at where at.tdate > GETDATE( ) - 10 order by at.tdate desc A instrução SQL acima é executada milhões de vezes por dia em um SGBDR Microsoft SQL Server. Considerando que ‘customerid’ é parte da chave primária e que ‘tdate’ não está indexada e não apresenta valores únicos, assinale o índice a seguir que irá prover uma melhor otimização para essa consulta.
- A)CREATE NONCLUSTERED INDEX st_tdate_ix1 ON salestransaction (tdate) GO
Errada, porque indexar apenas tdate ajuda no filtro, mas não cobre customerid e pode gerar lookup na tabela para completar a consulta.
- B)CREATE UNIQUE INDEX st_tdate_ix1 ON salestransaction (tdate, customerid) GO
Errada, porque o índice único em (tdate, customerid) não faz sentido aqui, já que tdate não é único e customerid não melhora o filtro nem a ordenação.
- C)CREATE NONCLUSTERED INDEX st_tdate_ix1 ON salestransaction (tdate)INCLUDE ([customerid]) GO
Certa, porque o índice em tdate com INCLUDE de customerid cobre a consulta, ajuda no WHERE e reduz leituras desnecessárias ao evitar lookup.
- D)CREATE CLUSTERED INDEX st_tdate_ix1 ON salestransaction (tdate)INCLUDE ([customerid]) GO
Errada, porque clustered index não aceita INCLUDE dessa forma e, além disso, a proposta não é adequada ao formato pedido pelo enunciado.
- E)CREATE PRIMARY XML INDEX st_tdate_ix1 ON salestransaction (tdate, customerid) WITH (XML_COMPRESSION = ON);
Errada, porque PRIMARY XML INDEX é para colunas XML, não para essa consulta relacional comum, então a sintaxe e o objetivo estão fora do tema.
Gabarito: C
A lógica aqui é simples: a consulta filtra por tdate, ordena por tdate desc e ainda precisa retornar customerid. Em SQL Server, o melhor cenário é ter um índice que ajude no predicado WHERE e, ao mesmo tempo, evite leitura extra da tabela para buscar a coluna projetada. Quando você coloca tdate como chave do índice, o SGBD consegue localizar rapidamente os registros dos últimos 10 dias e também já deixá-los na ordem desejada pelo ORDER BY, reduzindo trabalho de ordenação. O detalhe decisivo é o customerid: como ele faz parte da chave primária, muitas vezes já está presente no índice clustered ou na estrutura base da tabela, mas a questão pede a melhor otimização para essa consulta em especial. Um índice não clusterizado em tdate com INCLUDE em customerid torna a consulta coberta, isto é, o SQL Server consegue responder sem ficar indo e voltando à tabela para buscar customerid. Isso reduz I/O e costuma ser exatamente o tipo de ganho que banca adora cobrar. Por que não usar uma chave composta com customerid? Porque customerid não ajuda no filtro nem na ordenação desta consulta; ele só aumenta o tamanho e a complexidade do índice sem benefício real para o acesso. E como tdate não é único, a ideia de UNIQUE INDEX também não combina com o enunciado. Em resumo: você quer um índice enxuto, útil para o filtro, útil para a ordenação e que cubra a coluna retornada. É aí que a alternativa C brilha. Como regra prática em SQL Server, índices cobertos com INCLUDE são muito usados para evitar key lookup e melhorar consultas de leitura recorrente. A doutrina de performance de bancos de dados chama isso de covering index: o índice sozinho resolve a consulta, sem visitas extras aos dados.