DISTINCT先执行生成仅含SELECT字段的临时集，ORDER BY后执行且只能引用该集中的字段；若排序字段未出现在SELECT列表则报错，如MySQL的ERROR 1055。
ORDER BY 字段不在 SELECT 列表中直接报错
DISTINCT 先执行，生成一个只含 SELECT 列的临时结果集；ORDER BY 后执行，只能对这个临时集里的字段排序。一旦 ORDER BY 引用的字段（比如 created_at、id）没出现在 SELECT DISTINCT 的字段列表里，数据库就找不到排序依据，必然报错 —— 常见错误信息如 ERROR 1055（MySQL）、ORA-01791（Oracle）、ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list（PostgreSQL）。
典型错误写法：SELECT DISTINCT name FROM users ORDER BY created_at DESC
原因不是语法写错，而是执行逻辑上“先去重、再排序”，去重后结果里根本没有 created_at 这列。
加了排序字段进 SELECT 也不一定行得通
把 created_at 加进 SELECT 看似解决问题：SELECT DISTINCT name, created_at FROM users ORDER BY created_at DESC，但这时去重粒度变了：只要 name 和 created_at 组合不同就算一行，很可能你想要的是“每个 name 只取一条最新记录”，而不是所有时间戳都保留。
更隐蔽的坑是 COLLATE 场景：SELECT DISTINCT name FROM users ORDER BY name COLLATE "zh_CN.utf8" 仍会报错，因为 name COLLATE ... 是个新表达式，没在 SELECT 列表中显式出现。必须写成：SELECT DISTINCT name, name COLLATE "zh_CN.utf8" AS name_zh FROM users ORDER BY name_zh。
GROUP BY 通常比 DISTINCT + ORDER BY 更可靠
当目标是“按某字段去重，同时取关联字段的最新/最旧值”，GROUP BY 是语义更清晰、兼容性更好的选择：
SELECT name, MAX(created_at) AS latest FROM users GROUP BY name ORDER BY latest DESC- 如果还需返回其他字段（如
id），用窗口函数更稳妥：SELECT name, id, created_at FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY name ORDER BY created_at DESC) rn FROM users) t WHERE rn = 1 -
GROUP BY在 MySQL 5.7+ 默认开启ONLY_FULL_GROUP_BY模式下也更可控，不会因字段遗漏突然报错
子查询或 CTE 是最通用的绕过方案
不改语义、不依赖数据库特性的稳妥做法，是把去重和排序拆成两层：
例如想取每个 user_id 对应的最新订单时间，但只返回 user_id：
SELECT user_id
FROM (
SELECT user_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) ranked
WHERE rn = 1
ORDER BY created_at DESC;
或者用聚合子查询（兼容老版本）：SELECT user_id FROM orders o1 WHERE created_at = (SELECT MAX(created_at) FROM orders o2 WHERE o2.user_id = o1.user_id)，再在外层 ORDER BY —— 关键是外层 SELECT 的字段和 ORDER BY 字段完全对齐。
真正容易被忽略的点是：DISTINCT 的去重行为作用于整行，不是单列；而 ORDER BY 的字段哪怕只是参与排序、不用于展示，也必须“物理存在”于去重后的结果结构中 —— 这个约束在跨数据库迁移或升级版本（如 MySQL 5.7 → 8.0）时极易暴露。
