DISTINCT y ORDER BY fallan al ordenar por una columna no seleccionada

SELECT DISTINCT ciudad
FROM clientes
ORDER BY id;

Sin DISTINCT, ordenar por id aunque no lo muestres suele ser válido. Con DISTINCT ciudad, varias filas de clientes pueden convertirse en una sola ciudad. Entonces aparece una pregunta que la consulta no responde: si Madrid pertenece a los clientes 1, 3, 6 y 9, ¿qué id debería representar a la única fila «Madrid» al ordenar?

Por qué DISTINCT vuelve ambiguo un ORDER BY oculto

DISTINCT define la identidad del resultado a partir de las expresiones seleccionadas. Si seleccionas solo ciudad, todas las filas con el mismo valor se reducen a una. Una columna que no forma parte de esa identidad puede tener varios valores dentro del grupo de filas que acaba colapsándose.

Después de SELECT DISTINCT ciudad queda una sola fila «Madrid». Ordenarla por un id oculto sería ambiguo si no has definido qué id representa al grupo. Por eso la corrección no consiste simplemente en «hacer feliz al motor»: debes expresar qué orden quieres.

Error frecuente: añadir la columna a SELECT puede cambiar lo que DISTINCT significa

SELECT DISTINCT ciudad, id
FROM clientes
ORDER BY id;

Esta consulta ya no pide ciudades únicas. Pide combinaciones únicas de ciudad + id. Como id es único, prácticamente cada cliente vuelve a ser una fila distinta. Si tu objetivo era deduplicar ciudades, has cambiado la pregunta.

Tres correcciones según la intención real

1. Si solo quieres una lista ordenada de valores únicos, ordena por el propio valor

SELECT DISTINCT ciudad
FROM clientes
ORDER BY ciudad;

2. Si quieres ordenar cada valor único por una propiedad del grupo, define esa propiedad

Por ejemplo, «ciudades ordenadas por el primer cliente registrado en la tabla» sí tiene una regla concreta. Puedes agrupar por ciudad y ordenar por el menor identificador:

SELECT ciudad
FROM clientes
GROUP BY ciudad
ORDER BY MIN(id), ciudad;

La columna auxiliar no tiene que aparecer en la salida para que la intención sea válida: aquí MIN(id) se calcula de forma inequívoca para cada ciudad.

3. Si necesitas deduplicar primero y ordenar después por una clave auxiliar, separa las etapas

Una subconsulta o CTE puede convertir el criterio auxiliar en una columna explícita durante la deduplicación y dejar que la consulta exterior decida qué mostrar:

SELECT estado
FROM (
  SELECT DISTINCT
         estado,
         CASE estado
           WHEN 'pendiente' THEN 1
           WHEN 'enviado' THEN 2
           WHEN 'cancelado' THEN 3
           ELSE 4
         END AS prioridad
  FROM pedidos
) AS estados
ORDER BY prioridad, estado;

En este ejemplo, prioridad depende únicamente de estado, así que añadirla dentro de la deduplicación no crea duplicados nuevos. La consulta exterior devuelve solo estado.

La regla no es idéntica en todos los motores

Método de diagnóstico

1. Confirma que el error apareció al combinar DISTINCT y ORDER BY.
2. Marca qué expresiones forman realmente la identidad única que quieres devolver.
3. Comprueba si cada expresión de ORDER BY tiene un único valor para esa identidad.
4. Si no lo tiene, decide una regla: mínimo, máximo, fecha más reciente, prioridad calculada u otra medida explícita.
5. Evita añadir una clave única al SELECT DISTINCT si eso destruye la deduplicación.
6. Prueba la consulta final en el motor objetivo y verifica que el orden expresa la pregunta de negocio.

Práctica correctiva

SELECT ciudad
FROM clientes
GROUP BY ciudad
ORDER BY MIN(id), ciudad;

Conceptos relacionados

Fuentes técnicas

La interacción entre deduplicación y ordenación se contrastó con documentación primaria de cada motor:

• PostgreSQL: SELECT, DISTINCT y ORDER BY
• PostgreSQL: explicación del error DISTINCT + ORDER BY
• MySQL 8.4: DISTINCT, ORDER BY y ONLY_FULL_GROUP_BY
• SQL Server: limitaciones de ORDER BY con SELECT DISTINCT
• SQLite: SELECT, DISTINCT y ORDER BY