Questão de Banco de Dados e Gestão da Informação · FGV SEFAZ-AM 2022 - Prova I (nº 51)

Consultas SQL lentas geralmente acontecem quando o banco de dados precisa ler muitos dados ou fazer operações complexas sem a ajuda de índices, que são como catálogos para encontrar informações rapidamente.

(A) Incorreta: A cláusula `DISTINCT` pode ser lenta por exigir ordenação ou uso de memória temporária para remover duplicatas, mas não impede o uso de índices de forma tão drástica quanto outras operações.
(B) Incorreta: A cláusula `EXISTS` é geralmente eficiente porque verifica a existência de registros e para a busca assim que encontra o primeiro, evitando varreduras completas desnecessárias.
(C) Correta: A cláusula `LIKE` é a mais problemática, especialmente com o uso de coringas no início (`%termo`), pois impede o uso de índices na coluna e força o banco a escanear todos os registros da tabela para cada linha, tornando-se extremamente lenta em tabelas grandes.
(D) Incorreta: A cláusula `NOT EXISTS` pode ser menos eficiente que `EXISTS` em alguns cenários e exige que o banco processe a subconsulta para cada linha da consulta externa, mas geralmente é mais otimizável que `NOT IN` e não impede o uso de índices como `LIKE %`. A armadilha aqui é associá-la a `NOT IN`, que é frequentemente problemática, mas `NOT EXISTS` é geralmente uma opção melhor e mais otimizável em muitos casos.
(E) Incorreta: A cláusula `ORDER BY` pode ser lenta se não houver um índice adequado para a ordenação, exigindo que o banco realize uma operação de classificação (sort) que consome recursos, mas pode ser otimizada com índices ou algoritmos de ordenação eficientes.