旧版本mysql 5.7等不支持窗口函数，需用关联子查询模拟rank()（e2.salary > e1.salary +1）或dense_rank()（e2.salary >= e1.salary + count(distinct)），性能差，须建(department,salary)联合索引；累计求和宜用自连接。
旧版本数据库（如 MySQL 5.7、SQLite 未启用窗口扩展、PostgreSQL OVER，不是语法写错，是解析器直接跳过——强行运行只会报 ERROR 1064 或 syntax error near OVER。升级是最省事的解法，但若不能升，就得用可落地的替代逻辑。
MySQL 5.7 怎么绕过 ROW_NUMBER() 和 RANK()
别指望变量能稳定工作：在子查询、JOIN 或多线程场景下，@row_number := @row_number + 1 顺序不可靠，且无法做 PARTITION BY 分组排名。
- 用自连接模拟排名：对每行统计“有多少行的排序字段值比它大”，再加 1，例如
(SELECT COUNT(*) + 1 FROM t2 WHERE t2.score > t1.score) - 若需分组内排名（类似
PARTITION BY dept），必须嵌套两层：外层按 dept 分组，内层对每组单独自连接计数 - 性能敏感时加复合索引：
INDEX(dept, score)，否则自连接会全表扫多次
SQLite 窗口函数到底开没开？怎么验证
SELECT sqlite_version() 只告诉你版本号 ≥ 3.25，不等于窗口函数就可用。很多预编译包（尤其是嵌入式或老旧发行版）默认禁用 ENABLE_WINDOW_FUNCTIONS。
- 先执行
SELECT sum(amount) OVER () FROM sales LIMIT 1;—— 成功返回结果才说明已启用 - 失败时错误通常是
no such function: sum ... OVER或直接提示near "OVER": syntax error - 无法改编译参数时，只能退回到子查询或应用层计算；别信文档说“支持”，得亲手测
跨库视图里用了 LAG/LEAD，迁到 MySQL 8.0 报错 Window 'w' lacks an ORDER BY clause
PostgreSQL 允许 LAG(x) OVER (PARTITION BY a) 不写 ORDER BY，但 MySQL 8.0 要求所有累计类窗口函数（包括 LAG、SUM、AVG）必须带 ORDER BY，否则拒绝执行。
- 统一补上确定性排序字段，比如
LAG(x) OVER (PARTITION BY a ORDER BY id)，哪怕id是主键 - 避免用
RANGE BETWEEN：MySQL 只认ROWS BETWEEN，RANGE会直接报错 - 字符串字段进
LAG前务必CAST：MySQL 对类型更严格，LAG(created_at)若created_at是VARCHAR，可能静默返回NULL
PostgreSQL 视图含 COALESCE(ISNULL(...))，同步到 MySQL 或 KingbaseES 失败
ISNULL 是 SQL Server 函数，PostgreSQL 和 MySQL 都不认；COALESCE 虽通用，但参数类型不一致时，PostgreSQL 会隐式转换，MySQL 和 KingbaseES（兼容 PostgreSQL）则更严格。
- 把
ISNULL(a, b)全部换成COALESCE(a, b) - 如果
a是数字、b是字符串，必须显式转类型：COALESCE(CAST(a AS CHAR), b)，否则在 KingbaseES 里报function coalesce(integer, text) does not exist - 别在视图里用
HAVING rn 引用窗口别名——所有主流数据库都不支持，必须拆成两层查询
真正麻烦的从来不是函数名替换，而是 ORDER BY 是否存在、类型是否显式统一、以及空值填充逻辑在不同引擎里是否真的一致。测试不能只看“跑通”，得比对结果行数、NULL 位置、重复值排名是否完全相同。
