ROW_NUMBER()是视图中加序号的首选，因其为标准SQL窗口函数，不依赖物理顺序、不修改数据，仅动态计算；语义清晰、跨数据库兼容（MySQL 8.0+等），但须带ORDER BY且避免不可靠排序（如RAND()），并注意外层查询可能重算序号。
为什么 ROW_NUMBER() 是视图中加序号的首选
因为它是标准 SQL 窗口函数，不依赖物理表顺序，也不修改数据本身，只在查询时动态计算。相比用变量（如 @row := @row + 1）或子查询自连接，它语义清晰、可读性强，且在 MySQL 8.0+、PostgreSQL、SQL Server、Oracle 中都原生支持。
注意：MySQL 5.7 及更早版本不支持窗口函数，强行使用会报错 ERROR 1064 (42000)；若必须兼容旧版，得换方案（比如用临时表+变量），但那已不属于“视图内自动生成”的范畴。
在视图定义里写 ROW_NUMBER() 的正确姿势
关键点是：必须带 OVER 子句，且不能省略排序依据——即使你只是想要“原始插入顺序”，也得明确指定一个稳定、唯一、非空的列（比如主键 id）作为 ORDER BY。否则语法错误，或结果不可预测。
CREATE VIEW user_ranked AS SELECT ROW_NUMBER() OVER (ORDER BY id) AS seq, name, email FROM users;- 如果想按注册时间倒序排号，就写
ORDER BY created_at DESC；升序不用写ASC（默认） - 避免用
ORDER BY RAND()——它会让每次查视图序号都变，失去“序号”本意 - 不要在
OVER里写多个字段却没处理重复值，比如ORDER BY status, id没问题，但ORDER BY status（而 status 大量重复）会导致序号逻辑混乱
常见错误：视图里用 ROW_NUMBER() 却查不出连续序号
最常踩的坑是：视图定义没问题，但调用时又套了一层 WHERE 或 JOIN，导致序号重算或截断。例如：
SELECT * FROM user_ranked WHERE seq <= 10;
这看似取前 10 条，但实际是先生成全部序号再过滤——如果原表有 100 行，seq 就是 1~100，WHERE seq <= 10 才拿到前 10；但如果视图里本就加了 WHERE status = 'active'，那 seq 就只对活跃用户编号，不是全表连续。
- 序号永远基于视图定义时的
FROM和WHERE范围生成，不是调用时的范围 - 若需分页序号（如每页 20 条，第 2 页显示 21~40），应在外部查询用
LIMIT/OFFSET或OFFSET-FETCH，而不是指望视图里预生成“全局页内序号” - 别在视图里对
ROW_NUMBER()做WHERE过滤——视图定义中不能含WHERE seq = 1这类引用自身别名的条件，会报错Unknown column 'seq' in 'where clause'
性能和兼容性要注意什么
ROW_NUMBER() 是窗口函数，执行时需对 OVER 中的 ORDER BY 字段做排序，数据量大时可能触发磁盘临时表或慢查询。尤其当排序字段没索引，或视图被频繁 JOIN 时，代价明显。
- 确保
OVER子句里的排序字段（如id或created_at）上有索引 - PostgreSQL 中，若视图只用于小结果集，影响不大；但在 SQL Server 上，带窗口函数的视图有时无法被某些查询优化器下推，导致全表扫描
- Oracle 用户注意：
ROW_NUMBER()和RANK()、DENSE_RANK()行为不同——前者严格连续，后两者遇并列会跳号或不跳，别混用 - SQLite 直到 3.25.0 才支持窗口函数，旧版直接不识别
OVER关键字，报错near "OVER": syntax error
真正麻烦的从来不是怎么写那一行 ROW_NUMBER() OVER (ORDER BY ...)，而是想清楚这个序号到底依附于哪一层数据范围、是否会被外层查询无意破坏、以及排序字段有没有扛住压力的索引。
