Auditor do Estado - Ciências da Computação - Tarde (Conhecimentos Específicos)
Select at.customerid, at.tdatefrom salestransaction atwhere at.tdate > GETDATE( ) - 10order by at.tdate descA 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.
ACREATE NONCLUSTERED INDEX st_tdate_ix1 ONsalestransaction (tdate)GO
BCREATE UNIQUE INDEX st_tdate_ix1 ONsalestransaction (tdate, customerid)GO
CCREATE NONCLUSTERED INDEX st_tdate_ix1 ONsalestransaction (tdate)INCLUDE([customerid])GO
DCREATE CLUSTERED INDEX st_tdate_ix1 ONsalestransaction (tdate)INCLUDE([customerid])GO
ECREATE PRIMARY XML INDEX st_tdate_ix1 ONsalestransaction (tdate, customerid) WITH(XML_COMPRESSION = ON);
Revelar gabarito e comentário▾
GabaritoC — CREATE NONCLUSTERED INDEX st_tdate_ix1 ON
salestransaction (tdate)INCLUDE
([customerid])
GO
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Índices em SQL Server: otimização de consulta com filtro e ordenação
Gabarito: letra C. O índice NONCLUSTERED sobre tdate com a coluna customerid incluída (INCLUDE) cobre completamente a consulta: permite busca pelo filtro WHERE, mantém a ordenação por tdate e evita acessos à tabela base para obter customerid. As demais alternativas falham por violar a unicidade, não cobrir a consulta ou usar sintaxe inválida.
A questão testa o conceito de covering index (índice de cobertura) e a diferença entre colunas-chave e colunas incluídas. A consulta filtra por tdate > GETDATE()-10 e ordena por tdate DESC; além disso, projeta customerid. Para máxima eficiência, o índice deve conter tdate como chave (para ordenação e busca) e customerid como coluna incluída, sem participar da árvore do índice.
Critério
Alternativa A
Alternativa B
Alternativa C (Gabarito)
Alternativa D
Alternativa E
Tipo de índice
NONCLUSTERED
UNIQUE (NONCLUSTERED)
NONCLUSTERED
CLUSTERED
PRIMARY XML INDEX
Coluna(s)-chave
tdate
tdate, customerid
tdate
tdate
tdate, customerid
Coluna(s) incluída(s)
Nenhuma
Nenhuma
customerid
customerid
N/A
Cobre a consulta?
Não (falta customerid)
Sim (se criado)
Sim
Sim
Não (índice XML inválido para colunas comuns)
Ordenação por tdate DESC
Sim (índice pode ser percorrido reversamente)
Sim
Sim
Sim
Não
Risco de violação de unicidade
Não
Sim (tdate não é único)
Não
Não
Sim (sintaxe inválida)
Eficiência (key lookups)
Alta (precisa de lookups)
Média (índice mais largo)
Nenhuma (covering index)
Nenhuma (tabela reorganizada)
N/A
Sintaxe válida?
Sim
Sim
Sim
Sim
Não (XML_COMPRESSION não se aplica)
Alternativa A — ❌ Incorreta
Cria um índice não clusterizado apenas em tdate. A consulta também precisa de customerid, que não está no índice. Isso força um key lookup (busca na tabela por cada linha encontrada), o que é custoso, especialmente em milhões de execuções diárias.
Alternativa B — ❌ Incorreta
Tenta criar um índice unique sobre (tdate, customerid). O enunciado afirma que tdate não tem valores únicos, e não há garantia de que o par seja único. Um índice UNIQUE falharia ao inserir duplicatas. Além disso, mesmo que funcionasse, não é a melhor opção porque coloca ambas as colunas como chave, o que torna o índice mais largo e menos eficiente para a ordenação.
Alternativa C — ✅ Correta ⟵ GABARITO
CREATE NONCLUSTERED INDEX … ON (tdate) INCLUDE ([customerid]). Esse é um covering index para a consulta. O índice ordena por tdate (permite busca por intervalo e ordenação descendente) e inclui customerid como coluna não-chave, sem ocupar espaço na árvore B+ mas disponível em suas folhas. Isso elimina a necessidade de acessar a tabela: o SQL Server pode responder a consulta apenas percorrendo o índice.
Alternativa D — ❌ Incorreta
Um índice clustered reorganiza fisicamente a tabela pela chave escolhida. Porém, no SQL Server, a tabela já possui uma chave primária (que por default gera um índice clusterizado). Criar outro índice clusterizado exigiria remover o anterior ou criar a tabela sem clusterização, o que não é o caso. Além disso, a sintaxe INCLUDE é inválida para CREATE CLUSTERED INDEX – essa cláusula só existe para índices não clusterizados.
Alternativa E — ❌ Incorreta
PRIMARY XML INDEX é um tipo especial de índice para colunas com tipo de dados XML. A consulta opera sobre colunas comuns (customerid e tdate), não sobre XML. A sintaxe XML_COMPRESSION também não se aplica aqui. A alternativa é completamente descabida.
PEGA ESSA DICA!
Em consultas com filtro + ordenação + projeção de colunas adicionais, o covering index com INCLUDE é a ferramenta ideal. Lembre-se: colunas usadas no WHERE e ORDER BY vão como chave do índice; colunas apenas projetadas vão como included columns. Isso economiza largura do índice e evita lookups.