窗口函数无完全跨库兼容写法，核心差异在于over()中order by和rows/range支持度：postgresql最宽松，mysql 8.0+次之，sql server限制最多；安全跨库仅限row_number()/rank()配合partition by与order by、count(*) over(partition by ...)等基础用法。
窗口函数在 PostgreSQL / MySQL / SQL Server 之间的语法差异
没有“完全跨库兼容”的窗口函数写法，核心矛盾在于 OVER() 子句中对 ORDER BY 和 ROWS/RANGE 的支持程度不同。PostgreSQL 最宽松，MySQL 8.0+ 支持大部分标准语法，SQL Server 则对 RANGE 和部分帧定义限制较多。
常见报错包括：ERROR 1064 (42000): You have an error in your SQL syntax（MySQL 5.7 或旧版 SQL Server）、Window function is not allowed in this context（SQL Server 2012 之前或误用在 WHERE 中）。
- 所有数据库都要求
OVER()必须显式写出，不能省略（哪怕不排序、不分区） -
PARTITION BY在三者中行为一致，但若分区字段含 NULL，PostgreSQL 和 SQL Server 将 NULL 视为同一组，MySQL 8.0 默认也如此，但开启sql_mode=PAD_CHAR_TO_FULL_LENGTH可能影响比较逻辑 -
ORDER BY在OVER()中不是可选的——只要用了ROW_NUMBER()、RANK()或任何带帧的聚合（如SUM() OVER(... ROWS BETWEEN ...)），就必须有ORDER BY，否则 PostgreSQL 报错，MySQL 8.0 拒绝执行，SQL Server 直接语法错误
哪些窗口函数能安全跨库使用？
真正能“写一次、跑三地”的只有最基础的无帧、单列排序场景。优先选择语义明确、实现收敛的函数：
-
ROW_NUMBER() OVER(PARTITION BY a ORDER BY b)：三者均支持，且结果确定（无并列） -
RANK() OVER(PARTITION BY a ORDER BY b)：支持，但注意 MySQL 8.0 和 SQL Server 对并列项后跳位处理一致（如 1,1,3），PostgreSQL 同样 -
COUNT(*) OVER(PARTITION BY a)：安全，等价于分组计数，不依赖排序 - 避免使用
LAG()/LEAD()的默认 offset（如LAG(x)），因为 MySQL 8.0 要求显式写LAG(x, 1)，而 SQL Server 允许省略；统一写成LAG(x, 1) OVER(...) - 绝对不要用
FIRST_VALUE()配RANGE UNBOUNDED PRECEDING—— SQL Server 不支持RANGE帧用于该函数，会报Incorrect syntax near 'RANGE'
如何绕过 ROWS BETWEEN 的兼容性问题？
需要滑动窗口聚合（如 7 日累计）时，ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 在 SQL Server 2016+ 和 MySQL 8.0+ 可用，但 PostgreSQL 虽支持却可能因数据分布导致边界计算偏差（尤其时间字段含重复值）。更稳妥的做法是放弃物理行偏移，改用逻辑时间范围 + 自连接或 CTE 模拟：
SELECT t1.id, t1.dt,
(SELECT SUM(t2.val)
FROM tbl t2
WHERE t2.dt BETWEEN DATE_SUB(t1.dt, INTERVAL 6 DAY) AND t1.dt
AND t2.category = t1.category) AS sum_7d
FROM tbl t1;
虽然性能不如原生窗口函数，但它在任意 SQL 数据库上都能运行，且语义清晰可控。如果必须用窗口函数提速，可针对目标库单独维护两套查询：对 PostgreSQL/MySQL 用 ROWS，对 SQL Server 改用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 配合 PARTITION BY + 时间字段排序，再在外层过滤日期范围。
WHERE/HAVING 中误用窗口函数的典型陷阱
所有数据库都禁止在 WHERE 或 HAVING 中直接引用窗口函数结果，例如 WHERE ROW_NUMBER() OVER(...) > 1 会报错。这不是兼容性问题，而是 SQL 执行顺序导致的通用限制。
- 正确做法是嵌套子查询或 CTE：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER(...) rn FROM t) t1 WHERE t1.rn > 1 - MySQL 8.0 支持 CTE，SQL Server 2005+、PostgreSQL 9.1+ 都支持，所以 CTE 是最干净的跨库写法
- 别试图用变量模拟（如 MySQL
@rn := @rn + 1），它在多线程或优化器重排下不可靠，且 SQL Server 和 PostgreSQL 不支持同类语法 - 某些 ORM（如 Django ORM、SQLAlchemy）生成的子查询可能隐式触发该问题，需检查最终 SQL 是否把窗口函数放在了
WHERE左侧
真正的难点不在语法拼凑，而在理解每种数据库对“窗口边界”和“执行时序”的底层处理差异——比如 PostgreSQL 允许在同一个 SELECT 中多次引用同一窗口定义（通过 WINDOW w AS (...)），而其他数据库不支持，这种便利性一旦用上，就自动放弃了兼容性。
