ORDER BY 后不能直接用 DISTINCT，因语义冲突且标准不支持；应使用 ROW_NUMBER() 窗口函数按确定字段（如 id）去重保序，或用子查询取 MIN(id)，避免 GROUP BY 隐式字段陷阱。
ORDER BY 后用 DISTINCT 会报错，因为 SQL 标准不支持
直接写 SELECT DISTINCT col FROM t ORDER BY id 在多数数据库（如 PostgreSQL、SQL Server）会报错，提示“ORDER BY 项必须出现在 SELECT 列表中”或“DISTINCT 和 ORDER BY 冲突”。根本原因是 DISTINCT 语义上发生在 ORDER BY 之前，无法保证“先按原顺序去重，再取前 N 条”——原顺序本身可能没被显式保留。
用 ROW_NUMBER() + 窗口函数按原始顺序去重
核心思路：先给每行打上“首次出现的序号”，再过滤出每个分组的第一条。关键在于定义“原顺序”——通常指表中物理插入顺序不可靠，应依赖一个明确的排序字段（如自增 id 或时间戳 created_at）。
示例（取每个 user_id 首次出现的前 5 条记录，按 id 升序）：
SELECT user_id, content
FROM (
SELECT user_id, content, id,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY id) AS rn
FROM logs
) t
WHERE rn = 1
ORDER BY id
LIMIT 5;
-
PARTITION BY user_id定义去重维度 -
ORDER BY id确保“首次”是按真实插入顺序，不是随机选 - 外层
ORDER BY id LIMIT 5才是最终结果的顺序和数量控制
MySQL 8.0+ 可用窗口函数，旧版需用相关子查询模拟
MySQL 5.7 及更早不支持窗口函数，得用关联子查询或变量技巧。但变量方式（@prev :=）在复杂查询或并行执行下不稳定，不推荐生产环境使用。
兼容性更强的子查询写法（性能较差，适合小表）：
SELECT l1.user_id, l1.content FROM logs l1 WHERE l1.id = ( SELECT MIN(l2.id) FROM logs l2 WHERE l2.user_id = l1.user_id ) ORDER BY l1.id LIMIT 5;
- 本质是“对每个
user_id，找最小id对应的那行” - 必须有索引
(user_id, id)，否则全表扫描极慢 - 若存在多行
id相同，需加额外条件（如主键）避免歧义
GROUP BY 能不能替代？小心隐式字段和 MySQL 特性陷阱
有人试 SELECT user_id, content FROM logs GROUP BY user_id ORDER BY id LIMIT 5，这在 MySQL 5.7 默认 SQL 模式下可能“看似成功”，但 content 的值是未定义的——它来自哪个分组内行完全不确定，不同版本、不同执行计划结果都可能变。
- 标准 SQL 要求
GROUP BY后所有非聚合字段必须出现在GROUP BY子句中 - PostgreSQL、SQL Server 会直接报错：
column "content" must appear in the GROUP BY clause - 即使 MySQL 允许，也不能当作“取第一条”的可靠方案
真正需要“去重后取前 N 条且保序”，窗口函数是目前最通用、语义最清晰的解法；而“原顺序”永远要靠一个确定的排序字段来锚定，而不是幻想数据库记住插入顺序。
