SQL视图本身不支持直接分页，分页必须作用于查询视图的外层SQL；正确做法是在SELECT视图语句中添加ORDER BY配合OFFSET FETCH（SQL Server/PostgreSQL）或LIMIT OFFSET（MySQL），且ORDER BY不可省略，否则分页结果不可靠。
SQL视图本身不支持直接分页
视图只是封装好的 SELECT 语句，它不保存数据、不带分页逻辑，也不能像表一样被 LIMIT 或 OFFSET 直接修饰。你真正要分页的，是“查询视图的结果”，而不是“对视图做分页”。所以所有分页操作都必须落在查询视图的外层 SQL 上。
在查询视图时加 OFFSET FETCH 或 LIMIT OFFSET
这是最直接、最通用的做法，适用于 PostgreSQL、SQL Server 2012+、Oracle 12c+ 和 MySQL 8.0+（MySQL 8.0 支持 OFFSET，但语法是 LIMIT offset, size 或 LIMIT size OFFSET offset）。
- 假设你有一个视图
v_user_audit，想查第 3 页、每页 20 条，按create_time DESC排序 - PostgreSQL / SQL Server 写法：
SELECT * FROM v_user_audit ORDER BY create_time DESC OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;
- MySQL 写法：
SELECT * FROM v_user_audit ORDER BY create_time DESC LIMIT 20 OFFSET 40;
- 注意：
ORDER BY必须存在，否则OFFSET FETCH在 SQL Server/PostgreSQL 中会报错；MySQL 虽不强制，但无序分页结果不可靠
WHERE 条件必须写在外层或视图定义里
如果分页需要带条件（比如只查 status = 'pending'），有两种安全做法：
- 推荐：把条件写在查询视图的外层，和分页一起控制
SELECT * FROM v_user_audit WHERE status = 'pending' ORDER BY create_time DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
- 次选：把常用过滤条件下推到视图定义中（如
CREATE VIEW v_pending_users AS SELECT * FROM users WHERE status = 'pending'），再对这个视图分页——这样能复用，但灵活性下降 - 避免：在视图里硬编码参数（如用变量或函数），多数数据库不支持，且会导致执行计划不稳定
- 特别注意：如果视图内部已有
ORDER BY，外层再加ORDER BY会覆盖它；而分页依赖确定顺序，所以外层ORDER BY不可省略
性能陷阱：视图 + 分页 ≠ 自动优化
视图不会自动帮你优化底层查询。如果 v_user_audit 是基于多表 JOIN 或复杂子查询构建的，每次分页都会完整执行整个视图逻辑，再截取结果——这意味着：
- 即使只取 10 行，也可能扫描数百万行中间结果
- 没有合适索引时，
OFFSET 100000会越来越慢（深度分页问题） - 解决方案不是换写法，而是检查视图所依赖的表是否有覆盖索引，例如：
(status, create_time)联合索引对WHERE status = ? ORDER BY create_time DESC分页极关键 - 极端场景（如日志类大表分页），考虑改用 keyset 分页（用上一页最后一条的
create_time和id做条件），绕过OFFSET的线性扫描开销
视图分页真正的复杂点不在语法，而在于你是否清楚视图展开后的实际执行路径——它可能比你想象中更重，也更容易被索引策略拖垮。
