Tienes ya todas las piezas de una consulta menos una: decidir cuántas filas quieres recibir. Con las 20 filas de productos parece irrelevante, pero el día que te conectes a una tabla de producción con cincuenta millones de registros, un SELECT * FROM pedidos; sin más puede colapsar tu terminal, saturar la red y hacer que un administrador de sistemas te busque con cara de pocos amigos. LIMIT es la primera línea de defensa. Y es también la base de la paginación, uno de esos problemas que parecen resueltos en dos minutos y que en tablas grandes se convierten en un dolor de cabeza clásico. En esta lección aprenderás ambas cosas: el uso cotidiano y el uso serio.

1. LIMIT: acotar el resultado
2. Por qué LIMIT sin ORDER BY no es determinista
3. OFFSET y la paginación clásica
4. Los dos problemas de OFFSET en tablas grandes
5. Paginación por cursor o keyset
6. FETCH FIRST n ROWS ONLY: la forma estándar
7. Casos de uso típicos
8. LIMIT en el orden lógico de ejecución
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

LIMIT n indica cuántas filas, como máximo, quieres recibir. Se escribe al final de la consulta, después de ORDER BY:

Los cinco productos más caros del catálogo. Este patrón —ordenar y recortar— es la forma canónica de responder a cualquier pregunta de tipo "top N".

Comportamiento de LIMIT en los casos límite:

El uso más frecuente en el día a día ni siquiera lleva ORDER BY: es echar un vistazo a una tabla que no conoces.

Aquí SELECT * y la ausencia de ORDER BY son perfectamente legítimos: no quieres unas filas concretas, quieres ver qué pinta tienen los datos. Es exploración, no un informe.

Costumbre profesional: cuando te conectes a una base de datos que no conoces, escribe LIMIT 10 antes de escribir el resto de la consulta. Cuesta ocho caracteres y evita el bochorno de bloquear una sesión en producción.

Retomamos la advertencia de 02-05, porque con LIMIT se vuelve mucho más peligrosa.

¿Qué has pedido exactamente? Tres filas cualesquiera. No las tres primeras por id, no las tres más baratas: tres filas arbitrarias, las que el motor tuviera más a mano. Que hoy salgan la 1, la 2 y la 3 es casualidad del orden físico.

La diferencia con una consulta sin LIMIT es sutil pero crucial:

En el primer caso, ordenar el resultado en tu aplicación arregla el problema. En el segundo no hay arreglo posible: has perdido 17 filas y no sabes cuáles.

Regla: LIMIT sin ORDER BY solo es aceptable para explorar. En cuanto el resultado se use para algo, el ORDER BY es obligatorio, y debe ser determinista (terminado en una columna única, como viste en 02-05).

OFFSET m descarta las primeras m filas del resultado antes de aplicar LIMIT. Combinados, permiten recorrer un resultado grande en trozos:

Veámoslo con el catálogo de TiendaVerde ordenado por precio descendente y páginas de cinco productos.

Página 1 — LIMIT 5 OFFSET 0:

Página 2 — LIMIT 5 OFFSET 5:

Página 3 — LIMIT 5 OFFSET 10:

Y la cuarta y última cerraría con los productos 2, 18, 14, 4 y 5.

Resumen del cálculo:

Detalles importantes:

• El ORDER BY es obligatorio. Sin él, cada página se calcula sobre un orden distinto y podrías ver el mismo producto en dos páginas y otro en ninguna.
• El ORDER BY debe ser determinista. Por eso hemos escrito ORDER BY precio DESC, id: si dos productos costaran lo mismo, el desempate por id garantiza que siempre caigan en la misma página.
• OFFSET sin LIMIT es válido: OFFSET 15 devuelve las filas de la 16 en adelante.
• OFFSET mayor que el total devuelve cero filas, sin error. OFFSET 100 sobre productos no da nada.

Esta paginación funciona, es la que aprende todo el mundo, y tiene dos defectos serios que solo se manifiestan cuando los datos crecen.

OFFSET m no salta las primeras m filas: las calcula y las descarta. El motor no tiene forma de adivinar cuál es la fila número 500 001 sin haber producido las 500 000 anteriores.

La última página de un listado grande puede tardar cientos de veces más que la primera. Es un patrón conocido: los usuarios se quejan de que "la web va lenta al final del catálogo", y la causa está aquí. Con EXPLAIN ANALYZE (módulo 8) se ve con toda claridad en el nodo Limit, que informa de cuántas filas ha descartado.

Este es peor, porque no es lento: es incorrecto.

Imagina que un usuario está viendo la página 1 del catálogo ordenado por precio descendente y, en ese instante, alguien da de alta un producto de 25 € (más caro que el matcha). Cuando el usuario pulse "siguiente":

El usuario ve el producto 13 dos veces. Y con un borrado ocurre lo contrario: una fila desaparece sin haberse mostrado nunca.

Cada página es una consulta independiente, ejecutada en un momento distinto y sobre un estado distinto de la tabla. OFFSET no tiene memoria de lo que ya te enseñó.

¿Cuándo se puede vivir con OFFSET?

La alternativa consiste en dejar de decir "sáltate 500 000 filas" y empezar a decir "dame lo que viene después de esto". En lugar de una posición, se recuerda el último valor visto.

Volvamos a nuestro catálogo. La página 1 terminaba en el producto 13, con precio 13.75 €. La página 2 se pide así:

Idéntica a la página 2 de la sección 3, pero obtenida sin descartar nada: el motor va directo a las filas que cumplen precio < 13.75.

Qué pasa si hay empates. Si dos productos costaran exactamente 13.75 €, WHERE precio < 13.75 se saltaría el segundo. La solución es comparar la tupla completa de las columnas de ordenación, algo que SQL permite:

La comparación (precio, id) < (13.75, 13) es lexicográfica: se cumple si precio < 13.75, o si precio = 13.75 y además id < 13. Es exactamente la condición "estrictamente después del último elemento visto" para ese orden. Ojo con un detalle: para que la comparación de tuplas encaje, todas las columnas del ORDER BY deben ir en el mismo sentido, por eso aquí aparece id DESC.

Comparativa de los dos enfoques:

En la práctica: si tu interfaz es un scroll infinito o un botón "cargar más", el keyset es siempre la respuesta correcta. Si necesitas numeritos de página clicables, OFFSET es lo único viable y hay que asumir sus límites (o limitar el número de páginas navegables, que es lo que hacen casi todos los buscadores).

Para que el keyset rinda hace falta un índice sobre las columnas de ordenación, en este caso (precio, id). Sin él, PostgreSQL tiene que ordenar toda la tabla igualmente y no ganas nada. Los índices son el módulo 8.

LIMIT es cómodo, universalmente conocido... y no es SQL estándar. Lo introdujo MySQL, lo adoptó PostgreSQL y hoy lo entienden casi todos los motores, pero la sintaxis oficial del estándar SQL:2008 es otra:

Exactamente el mismo resultado. PostgreSQL admite ambas formas y las trata igual.

PostgreSQL añade además WITH TIES, que amplía el resultado para incluir todas las filas empatadas con la última:

Sobre estos datos devuelve las mismas 5 filas, porque no hay dos productos con el mismo precio. Pero si hubiera tres productos a 13.75 €, WITH TIES devolvería 7 filas en lugar de 5: es la forma correcta de hacer un "top 5" honesto en una competición. WITH TIES exige ORDER BY y no funciona con LIMIT, solo con FETCH.

Tabla comparativa entre motores:

Dos trampas de esta tabla que conviene subrayar:

1. LIMIT m, n de MySQL invierte el significado: el primer número es el desplazamiento y el segundo la cantidad. LIMIT 5, 10 en MySQL es LIMIT 10 OFFSET 5 en PostgreSQL. Una consulta copiada sin leerla devuelve datos equivocados.
2. ROWNUM de Oracle se asigna antes del ORDER BY. WHERE ROWNUM <= 5 ORDER BY precio DESC devuelve cinco filas cualesquiera y luego las ordena: no es el top 5. Hay que ordenar en una subconsulta y aplicar ROWNUM fuera.

¿Cuál usar? En este curso, LIMIT: es lo que verás en el 99 % del código PostgreSQL. Si escribes SQL que deba ejecutarse en varios motores, OFFSET ... FETCH FIRST ... ROWS ONLY es la apuesta segura.

Ya lo has visto con los productos más caros. Otra variante, los cinco de mayor margen:

Fíjate en que las Cápsulas de espirulina (margen 7.70 €, tercera del catálogo) no aparecen: el WHERE activo las descarta antes de ordenar. El orden lógico manda: primero se filtra, después se ordena, y solo al final se recorta.

Los tres últimos pedidos recibidos: el contenido natural de un panel de "actividad reciente".

La primera clienta de TiendaVerde. Este patrón —ORDER BY ... LIMIT 1— es equivalente a usar MIN/MAX, pero con una ventaja: te devuelve la fila entera, no solo el valor mínimo. Con MIN(fecha_registro) sabrías la fecha, pero no quién es. Las funciones de agregación llegan en la lección 04-04.

Con LIMIT se completa el ciclo que empezamos en 02-01. Este es el diagrama definitivo del módulo:

LIMIT es siempre lo último. De ahí salen consecuencias que conviene tener claras:

Ese último punto merece un matiz. Aunque lógicamente se ordene todo, PostgreSQL es más listo que eso: cuando ve un ORDER BY ... LIMIT n pequeño, usa un algoritmo llamado top-N heapsort, que mantiene en memoria solo las n mejores filas vistas hasta el momento en lugar de ordenar el conjunto entero. Y si existe un índice que ya devuelve las filas en el orden pedido, puede leer las n primeras y parar, sin tocar el resto de la tabla.

Es el ejemplo perfecto de la distinción de 02-01: el orden lógico define el significado de la consulta, y el plan físico que elige el optimizador puede ser radicalmente más eficiente mientras produzca el mismo resultado. Lo verás con tus propios ojos en el módulo 8 con EXPLAIN.

• LIMIT sin ORDER BY en cualquier consulta que no sea exploratoria. Devuelve filas arbitrarias y el problema no se puede arreglar después.
• ORDER BY no determinista al paginar. Si hay empates y no los desempatas con una columna única, una misma fila puede aparecer en dos páginas y otra en ninguna.
• Copiar LIMIT 10, 20 de un ejemplo de MySQL. En MySQL significa "20 filas desde la 11"; en PostgreSQL ni siquiera es sintaxis válida.
• Creer que OFFSET salta filas sin coste. Las produce y las tira. En la página 5 000 lo notarás.
• Paginar con OFFSET sobre datos que cambian. Filas repetidas y filas saltadas, sin ningún error que lo delate.
• Aplicar el keyset con un ORDER BY que no coincide con la condición del WHERE. Las columnas deben ser las mismas, en el mismo orden y en el mismo sentido.
• Usar LIMIT para "arreglar" una consulta lenta. Si la consulta es lenta por falta de índice, LIMIT puede seguir siendo lento: el motor tiene que encontrar las filas antes de recortarlas.
• Esperar que LIMIT 1 sustituya a un WHERE bien escrito. Devolver una fila cualquiera de las que cumplen la condición rara vez es lo que se quiere.
• Consejo: LIMIT primero, consulta después. Al explorar una base desconocida, escríbelo antes de nada.
• Consejo: LIMIT 0 es útil. Te da las columnas y sus tipos sin traer datos, ideal para comprobar la forma de una consulta compleja.
• Consejo: para un "top N" honesto, plantéate FETCH FIRST n ROWS WITH TIES. Cortar por el número 5 exacto cuando el 5 y el 6 empatan es engañoso.

Atención al cliente necesita un panel con los cinco pedidos más antiguos que todavía no están entregados ni cancelados, mostrando id, cliente_id, fecha_pedido, estado y gastos_envio. Escribe la consulta y explica cuántas filas devuelve realmente y por qué.

Construye la segunda página de un listado de clientes ordenado por país y, dentro de cada país, por apellidos, con páginas de cuatro clientes. Escríbela primero con OFFSET y después con paginación keyset. Explica qué información necesita la aplicación en cada caso para pedir la página siguiente.

El equipo de compras quiere las tres líneas de pedido de mayor importe. Escribe la consulta usando la sintaxis estándar FETCH FIRST, e indica qué cambiaría si usaras WITH TIES. Después responde: ¿por qué esta consulta no puede decirte de qué producto se trata?

Solución 1

5 filas, que resultan ser todas las que cumplen la condición: de los 20 pedidos, 14 están entregados y 1 cancelado, así que solo quedan 5 en curso. El LIMIT 5 no ha recortado nada, y ese es un comportamiento normal: LIMIT es un máximo, no una promesa.

El razonamiento por el orden lógico: FROM trae 20 filas → WHERE deja 5 → SELECT proyecta → ORDER BY fecha_pedido, id las ordena de más antigua a más reciente → LIMIT 5 no descarta ninguna. Si mañana entran diez pedidos nuevos, la consulta seguirá devolviendo los cinco más antiguos sin tocar una coma.

En el módulo 4 escribirás esa condición de forma más limpia como WHERE estado NOT IN ('entregado', 'cancelado').

Solución 2

Con OFFSET, la página 2 (clientes 5 a 8 del listado):

El listado completo ordenado por pais, apellidos empieza así: Belmonte Roca (5), Bosch Ferrer (13), Carrasco Vega (15), Ferrer Ibáñez (2) —página 1—, y continúa:

Con paginación keyset, partiendo del último elemento de la página 1 —Carlos Ferrer Ibáñez, país España, apellidos Ferrer Ibáñez, id 2—:

Devuelve exactamente las mismas cuatro filas.

Qué necesita la aplicación en cada caso:

Fíjate en dos detalles del keyset: la tupla del WHERE contiene exactamente las mismas columnas del ORDER BY y en el mismo orden, y se incluye id como última columna precisamente para desempatar dos clientes que compartieran país y apellidos. Sin ese id, un apellido repetido haría que se perdiera un cliente entre página y página.

Solución 3

Qué cambiaría con WITH TIES. Nada, en este caso: la cuarta línea vale 26.73 €, muy lejos de los 34.02 € de la tercera, así que no hay empate que arrastrar. Pero conviene notar que WITH TIES no puede llevar un desempate artificial en el ORDER BY: si dejas el , id final, cada fila tiene un valor de ordenación único y nunca habrá empates que incluir. Para que WITH TIES sirva de algo hay que ordenar solo por el criterio real:

Con estos datos devuelve las mismas 3 filas. Si hubiera dos líneas empatadas en 34.02 €, devolvería 4.

Por qué no puedes saber de qué producto se trata. Porque lineas_pedido guarda producto_id, un número, y el nombre del producto vive en la tabla productos. Con las herramientas de este módulo solo puedes consultar una tabla a la vez: lo máximo que puedes decir es que la línea 28 corresponde al producto 15. Para escribir "Té verde matcha ceremonial 30 g" en el informe hace falta combinar ambas tablas, y eso es precisamente lo que empieza en la lección siguiente.

Has cerrado el ciclo completo de una consulta:

• LIMIT n acota el resultado a un máximo de n filas y es la primera línea de defensa al explorar tablas grandes o desconocidas.
• LIMIT sin ORDER BY no es determinista: devuelve filas arbitrarias, y ese daño no se puede reparar después.
• OFFSET m descarta las primeras m filas y permite la paginación clásica LIMIT tamaño OFFSET (N-1)*tamaño, que exige un ORDER BY determinista.
• Esa paginación tiene dos defectos en tablas grandes: el coste crece con el número de página, y las inserciones o borrados hacen que se repitan o se salten filas.
• La paginación por cursor o keyset —WHERE (columnas) < (últimos valores vistos)— tiene coste constante y no se descuadra, a cambio de no poder saltar a una página arbitraria.
• FETCH FIRST n ROWS ONLY es la forma estándar, y WITH TIES amplía el resultado con las filas empatadas. Cada motor tiene su dialecto, y LIMIT m, n de MySQL invierte los argumentos.
• LIMIT es el paso 5 y último del orden lógico; el optimizador, sin embargo, sí aprovecha su presencia con estrategias como el top-N heapsort.

Y con esto cierras el módulo 2 completo. Sabes construir una consulta de principio a fin: elegir su origen con FROM, filtrar filas con WHERE, proyectar y calcular columnas con SELECT y sus alias, eliminar repeticiones con DISTINCT, imponer un orden con ORDER BY y recortar el resultado con LIMIT. Y sabes en qué orden lógico ocurre todo eso, que es lo que te ha permitido entender por qué un alias funciona en un sitio y no en otro.

Pero fíjate en el techo con el que has chocado una y otra vez: pedidos te dice cliente_id = 9 y no "Camille Dubois"; lineas_pedido te dice producto_id = 15 y no "Té verde matcha ceremonial"; productos te dice categoria_id = 2 y no "Cosmética natural". Todas tus consultas han mirado una sola tabla, y las preguntas que de verdad le interesan a TiendaVerde —qué compró cada cliente, qué categoría factura más, qué comercial cierra más pedidos, qué productos no ha comprado nadie— viven precisamente en las relaciones entre tablas que dibujaste en el diagrama de 01-06. En el módulo 3, Consultas con múltiples tablas, aprenderás a recorrer esas relaciones con JOIN: el INNER JOIN para lo que casa a ambos lados, el LEFT y el RIGHT para conservar lo que no casa —ahí aparecerán por fin los tres clientes sin pedidos y los tres productos nunca vendidos—, el FULL OUTER para ambas cosas a la vez, el SELF JOIN para las relaciones reflexivas de empleados y clientes, y UNION, INTERSECT y EXCEPT para combinar resultados enteros. Las nueve tablas de TiendaVerde dejan de ser nueve islas.