LIMIT, TOP e ROWNUM: Consultas Eficientes em Diferentes SGBDs

Retornar todas as linhas de uma tabela quando apenas uma amostra é necessária tem um custo real — de I/O em disco, de tráfego de rede e de tempo de resposta. Por isso, boa parte das boas práticas de consulta em bancos de dados relacionais começa por um princípio simples: solicitar apenas os dados que a aplicação efetivamente vai consumir.

Um dos mecanismos mais diretos para isso é a limitação do número de linhas retornadas. O comportamento é útil para amostragem de dados, testes, paginação e depuração de consultas — mas a sintaxe para implementá-lo varia significativamente entre os principais SGBDs relacionais.

MySQL, PostgreSQL e SQLite — cláusula LIMIT

Esses três sistemas adotam a cláusula LIMIT, aplicada ao final da consulta, após qualquer filtro ou ordenação:

SELECT * FROM owner
LIMIT 3;

Por ser processada depois do ORDER BY, a cláusula LIMIT retorna um subconjunto previsível: as primeiras N linhas do resultado já ordenado — desde que uma cláusula ORDER BY esteja presente. Sem ordenação explícita, a ordem das linhas retornadas não é garantida por padrão.

Oracle — pseudocoluna ROWNUM

O Oracle Database não possui uma cláusula LIMIT nativa em versões anteriores ao 12c. Em vez disso, utiliza a pseudocoluna ROWNUM, atribuída a cada linha à medida que ela é processada:

SELECT * FROM owner
WHERE ROWNUM <= 3;

Há um detalhe frequentemente ignorado por quem está migrando de outro SGBD: o ROWNUM é avaliado antes da cláusula ORDER BY. Isso significa que um filtro como WHERE ROWNUM <= 3 combinado com ORDER BY não retorna necessariamente as 3 primeiras linhas do resultado ordenado — ele numera as linhas conforme são lidas e só depois ordena o subconjunto já limitado. Para obter as N primeiras linhas de um resultado ordenado no Oracle, o padrão correto é aplicar o ROWNUM sobre uma subconsulta já ordenada, ou, a partir do Oracle 12c, utilizar a sintaxe ANSI OFFSET ... FETCH.

SQL Server — cláusula TOP

O SQL Server utiliza a cláusula TOP, posicionada logo após o SELECT:

SELECT TOP 3 *
FROM owner;

Assim como no MySQL, PostgreSQL e SQLite, o resultado só é previsível quando combinado a um ORDER BY. O SQL Server também aceita TOP com percentual (TOP 10 PERCENT) e a opção WITH TIES, para incluir linhas empatadas no critério de corte — um recurso sem equivalente direto em LIMIT.

A alternativa padrão ANSI: OFFSET e FETCH

Desde o SQL:2008, o padrão ANSI define a sintaxe OFFSET ... FETCH como forma portável de paginar e limitar resultados. Ela é suportada pelo SQL Server (a partir da versão 2012), pelo Oracle (a partir da versão 12c) e também pelo PostgreSQL:

SELECT * FROM owner
ORDER BY id
OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY;

Para times que trabalham com múltiplos SGBDs no mesmo ambiente — um cenário comum em migrações, integrações ou arquiteturas híbridas — adotar OFFSET ... FETCH onde disponível reduz a necessidade de reescrever consultas a cada troca de plataforma.

Reduzindo o volume de dados com WHERE e índices

Limitar o número de linhas no resultado final não é a única forma de tornar uma consulta mais eficiente. Aplicar filtros com a cláusula WHERE reduz o volume de dados processado internamente pelo motor do banco, antes mesmo de qualquer limitação de linhas ser aplicada.

Quando a coluna usada no filtro possui um índice adequado, o otimizador de consultas pode localizar as linhas relevantes diretamente pela estrutura do índice, em vez de percorrer a tabela inteira — operação conhecida como full table scan. Em tabelas grandes, essa diferença de estratégia de acesso costuma ter impacto direto e mensurável no tempo de resposta da consulta.

Resumindo

LIMIT, TOP e ROWNUM resolvem o mesmo problema — reduzir o volume de linhas retornadas — mas cada um impõe particularidades de posicionamento na query e de ordem de avaliação que afetam diretamente o resultado. Entender essas diferenças, e saber quando recorrer à sintaxe ANSI OFFSET ... FETCH, é o que separa uma consulta que funciona por acaso de uma consulta escrita com domínio real do SGBD utilizado.