窗口函数必须置于select列表中且正确使用over子句，不可出现在where、group by或on中；partition by与order by顺序固定，后者对排名函数为必需；rows按行位置、range按值范围界定窗口帧，性能与语义差异显著。
OVER 语法写错位置，SQL 直接报错
窗口函数必须搭配 OVER 子句，且不能出现在 WHERE、GROUP BY 或 ON 中——这些子句执行时，行集尚未按窗口定义完成排序和分组，ROW_NUMBER() 这类函数根本不可用。
常见错误现象：ERROR: window functions are not allowed in WHERE clause 或 syntax error at or near "OVER"，往往是因为把 OVER 写在了聚合函数外层、或套在 CASE WHEN 的条件表达式里却忘了括号层级。
-
SELECT name, ROW_NUMBER() OVER (ORDER BY score DESC) FROM students;✅ 正确：直接用于 SELECT 列表 -
WHERE ROW_NUMBER() OVER (...) > 1❌ 错误：WHERE 不允许窗口函数 -
GROUP BY ROW_NUMBER() OVER (...)❌ 错误：GROUP BY 也不支持 - 想筛“每个班级分数前3的学生”？得用子查询或 CTE 包一层，再在外层加 WHERE
PARTITION BY 和 ORDER BY 的顺序与必要性
PARTITION BY 定义窗口边界（类似分组），ORDER BY 定义窗口内排序逻辑；两者顺序固定，且 ORDER BY 对多数排名函数是强制的（如 RANK()、ROW_NUMBER()），但对 COUNT(*) OVER () 这种聚合型窗口函数可省略。
容易踩的坑：只写 PARTITION BY 不写 ORDER BY，结果看似正常，但 ROW_NUMBER() 会按随机物理顺序编号，不同执行可能出不同结果，线上环境极易引发数据不一致。
-
COUNT(*) OVER (PARTITION BY dept)✅ 合法，统计部门人数 -
ROW_NUMBER() OVER (PARTITION BY dept)⚠️ 危险！标准 SQL 要求必须有ORDER BY，PostgreSQL 允许但行为未定义 - 正确写法：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY hire_date) - 注意：
ORDER BY里的字段必须在 SELECT 中存在，或来自原始表（不能是别名，除非用子查询重命名）
ROWS BETWEEN 和 RANGE BETWEEN 的实际差异
默认窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但这个“CURRENT ROW”对 RANGE 是按值判断，对 ROWS 是按物理行位置判断——这是性能和语义差别的根源。
pui 是一款基于jQyery开发的插件库。目前线上稳定使用已有2年多，丰富的接口，简单明了的调用方式，灵活的回调函数，让您轻轻松松打造出富有灵活交互的Web前端界面解决方案。 插件库封装了布局、表单元素、表单校验、弹窗、toast、气泡pop、tab切换、日历时间、分页、表格、树、css命名等功能
使用场景：滚动平均、累计求和、同比计算。比如算“过去7天销售额”，用 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 更稳；而用 RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW（PostgreSQL 支持）更准，但可能因日期重复导致多行被纳入同一帧。
-
SUM(sales) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)→ 固定取最近3行 -
SUM(sales) OVER (ORDER BY date RANGE BETWEEN INTERVAL '2 days' PRECEDING AND CURRENT ROW)→ 取 date 值在 [t-2, t] 内所有行 - 如果某天有多条记录，
RANGE会全包进去，ROWS只看位置，不看时间值 - 性能上，
ROWS几乎总是更快；RANGE在大数据量 + 高频重复值时可能显著变慢
MySQL 8.0+ 和 PostgreSQL 的 OVER 兼容细节
MySQL 8.0 才开始支持窗口函数，但早期版本（如 8.0.0–8.0.16）对 FIRST_VALUE() 等函数的 NULL 处理和帧定义支持不完整；PostgreSQL 则从 8.4 就有实验性支持，9.0 后全面稳定，且支持更丰富的帧语法（如 GROUPS 模式）。
跨数据库移植时最容易翻车的是默认帧行为和 NULL 排序：MySQL 默认 NULLS LAST，PostgreSQL 默认 NULLS FIRST，不显式声明会导致排名错位。
- 安全写法：
ORDER BY status NULLS LAST，避免隐式差异 - MySQL 不支持
RANGE BETWEEN INTERVAL ...，只能用ROWS模拟 - PostgreSQL 支持
EXCLUDE CURRENT ROW等高级帧修饰，MySQL 目前不支持 - 如果用到
LAG(col, 2)，确保目标列类型兼容（比如不能对 JSON 字段直接 LAG）
真正麻烦的不是语法记不住，而是 ORDER BY 缺失时的静默错误，以及 PARTITION BY 字段含 NULL 时各数据库对“同组”的判定差异——这两处没测到，上线后数据就偏了。
