窗口函数与DISTINCT不能共存于同一层SELECT，因SQL执行顺序中DISTINCT在SELECT阶段生效，而窗口函数需依赖去重前的原始行集计算，二者语义冲突；替代方案包括改用GROUP BY、子查询或CTE。
窗口函数不能直接和 DISTINCT 同时出现在同一个 SELECT 语句的顶层——这是 SQL 标准限制，不是某个数据库的 bug。根本原因在于：窗口函数在逻辑上是在 DISTINCT 去重之后才执行的，但语法上又要求窗口函数必须“看到”原始行（否则无法计算排名、累计值等），二者语义冲突。
为什么 DISTINCT 和窗口函数不能共存于同一层 SELECT
SQL 的逻辑执行顺序决定了问题所在：
1. FROM/JOIN → 2. WHERE → 3. GROUP BY → 4. HAVING → 5. SELECT（此时 DISTINCT 生效）→ 6. ORDER BY
而窗口函数虽然写在 SELECT 子句里，但它实际依赖的是第 3 步（GROUP BY）之后、第 5 步（DISTINCT）之前的行集。一旦加了 DISTINCT，系统就无法确定窗口函数该基于哪套“未去重”的数据来计算。
所以像下面这样的写法会报错（以 PostgreSQL / MySQL 8.0+ / SQL Server 为例）：
SELECT DISTINCT user_id, COUNT(*) OVER (PARTITION BY user_id) FROM orders;
常见错误场景与替代方案
你真正想实现的，往往不是“对去重后的结果再开窗”，而是以下几种情况之一：
-
需要每个用户一条记录，同时附带该用户的订单总数 → 改用
GROUP BY+ 聚合函数，而不是DISTINCT：SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id; -
需要保留明细行，但只对每个用户的首次/最新订单打标 → 用窗口函数先算出序号，再外层过滤：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS rn FROM orders) t WHERE rn = 1; -
需要去重后统计某种比例（比如活跃用户占比） → 把窗口函数放进子查询或 CTE，再对外层结果去重或聚合：
WITH user_stats AS (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) SELECT COUNT(DISTINCT user_id) * 1.0 / COUNT(*) FROM user_stats;
特别注意：COUNT(DISTINCT) OVER (...) 是合法的
这个容易混淆：COUNT(DISTINCT col) OVER (PARTITION BY x) 是完全合法且常用的操作（如“每个品类下有多少个不同品牌”）。
它不是“先 DISTINCT 再开窗”，而是“在每个窗口内做去重计数”，属于窗口函数内部的聚合逻辑，不违反执行顺序规则。
但反过来：SELECT DISTINCT ..., SUM(x) OVER (...) ... 就非法 —— 因为 DISTINCT 作用于整个行，破坏了窗口函数所需的行粒度上下文。
不同数据库的行为差异提示
MySQL 8.0+ 和 PostgreSQL 会明确报错，提示类似 “DISTINCT and window functions are not supported together”。
SQLite 不支持窗口函数与 DISTINCT 混用，语法直接拒绝。
Oracle 允许写，但行为可能不符合预期（实际按未去重数据计算窗口，再对结果去重），容易引发数据误解。
因此，**不要依赖数据库的宽容，应主动重构逻辑**。
