Com referência à otimização de consultas SQL para bancos de dados relacionais, assinale a opção que apresenta a cláusula que potencialmente pode causar maiores problemas de desempenho, por si só, quando são manipuladas tabelas com grande número de registros.
- A)DISTINCT
DISTINCT pode exigir eliminação de duplicidades e custar caro, mas não é, em regra, a cláusula mais problemática por si só para grandes volumes.
- B)EXISTS
EXISTS costuma ser eficiente porque pode encerrar a busca assim que encontra uma linha que satisfaça a condição.
- C)LIKE
LIKE pode prejudicar o uso de índices em alguns padrões, mas não é a cláusula que a questão destaca como mais pesada isoladamente.
- D)NOT EXISTS
NOT EXISTS também é usado em testes de existência e, em geral, pode ser otimizado de forma eficiente pelo banco.
- E)ORDER BY
ORDER BY normalmente exige ordenação dos resultados, operação que pode consumir muito tempo, memória e disco em tabelas grandes.
Gabarito: E
Quando você pensa em desempenho de SQL, a primeira coisa é lembrar que nem toda cláusula pesa do mesmo jeito. Algumas filtram cedo, outras só organizam o resultado no fim. E é justamente aí que mora a diferença: ordenar costuma exigir que o banco compare, classifique e muitas vezes faça uso intenso de memória e disco, especialmente quando há muitos registros para processar. No caso da questão, a cláusula que mais pode gerar problema de desempenho, por si só, é o ORDER BY. Isso porque o banco precisa devolver os dados em uma ordem específica, o que normalmente implica etapa de sort. Em tabelas grandes, esse passo pode ser caro, principalmente se não houver índice adequado para atender à ordenação. É o tipo de comando que parece inocente, mas pode virar um treino de maratona para o banco. As demais opções não costumam pesar tanto isoladamente do mesmo jeito. EXISTS e NOT EXISTS geralmente servem para testar existência e podem ser bem eficientes, porque o banco pode parar a verificação assim que encontra uma linha compatível. DISTINCT também pode exigir eliminação de duplicidades, mas a questão fala em maior problema de desempenho, por si só, e a ordenação costuma ser ainda mais crítica em grandes volumes. Em resumo: em consultas com muitos registros, ORDER BY tende a ser o vilão mais clássico de custo alto, especialmente sem índice compatível. Em provas de SQL, a banca gosta dessa ideia de que ordenar grande volume de dados é uma operação pesada, e por isso a alternativa correta é a que aponta a ordenação.