row_number()是视图中加序号的首选，因其为标准sql窗口函数，不依赖物理顺序、不修改数据，仅动态计算；须带order by且避免不可靠排序，mysql 5.7及更早版本不支持。
创建含 ROW_NUMBER() 的视图必须用 CREATE VIEW 语法，且数据库需支持窗口函数
PostgreSQL 13+、SQL Server 2005+、Oracle 8i+、MySQL 8.0+ 都支持在视图中使用 ROW_NUMBER()；但 SQLite 和旧版 MySQL（Window function is not allowed in this context。创建前先确认版本：
SELECT VERSION();或
SELECT current_setting('server_version');
ROW_NUMBER() 在视图里不能带 ORDER BY 子句（除非嵌套在子查询中）
直接写 ROW_NUMBER() OVER (ORDER BY id) 是合法的，但若试图在视图定义里加顶层 ORDER BY（比如想让视图默认按某列排），会报错：ORDER BY is not allowed in a view definition。正确做法是把排序逻辑收进窗口函数内部：
CREATE VIEW user_rank_view AS SELECT id, name, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM users;
- 窗口函数的
ORDER BY是必须的——ROW_NUMBER()要依赖明确的排序依据，否则语法错误 - 别名（如
rn）必须显式声明，否则某些数据库（如 SQL Server）在查询视图时可能报Invalid column name - 避免在
OVER中引用视图外层的列或别名，只允许引用基表字段或已定义的表达式
视图默认“只读”？不完全是——得看底层表权限和数据库行为
SQL 标准不强制视图只读，是否可更新取决于实现。即使视图只含 ROW_NUMBER()，PostgreSQL 和 SQL Server 仍可能允许 INSERT/UPDATE（如果基表允许且无聚合/去重等限制），但这会导致序号逻辑失效甚至报错。要真正只读，需主动约束：
- PostgreSQL：用
CREATE VIEW ... WITH (security_invoker = false)不够，应配合REVOKE INSERT, UPDATE, DELETE ON user_rank_view FROM PUBLIC; - SQL Server：添加
WITH SCHEMABINDING并确保用户无底层表写权限 - MySQL：视图本身不可写（只要含窗口函数、聚合、子查询等），但权限控制仍建议显式
REVOKE INSERT ON view_name FROM 'user'@'%';
查询含 ROW_NUMBER() 的视图时，序号每次执行都重新计算
这不是 bug，是窗口函数语义决定的——ROW_NUMBER() 没有持久化，也不缓存。这意味着：
- 同一视图被多次
SELECT，只要基表数据或排序依据变了，rn值就可能不同 - 无法用它做稳定主键或外键引用（例如
JOIN时依赖rn = 1可能漏数据） - 性能上，每次查视图都会重跑整个窗口计算，大数据量下比物化视图慢得多；如需稳定序号，考虑建带自增列的物化表或使用
GENERATED ALWAYS AS（PostgreSQL 12+ 支持生成列，但不适用于动态排序场景）
真正容易被忽略的是：很多人以为给视图加个 ROW_NUMBER() 就能替代分页逻辑，结果在应用层做 WHERE rn BETWEEN 11 AND 20 时发现性能陡降——因为数据库无法下推过滤，必须先算完整个结果集再裁剪。
