SQL视图中不能直接使用LIMIT，因其破坏集合语义且标准SQL禁止；分页必须在外层查询加LIMIT和ORDER BY；深度分页应改用基于唯一排序字段的游标分页。
SQL视图里不能直接写 LIMIT
视图（VIEW）本质是保存的查询语句，不是真实表，标准 SQL（包括 MySQL、PostgreSQL）**不允许在 CREATE VIEW 语句中使用 LIMIT**。你如果强行加，会报错：ERROR 1356 (HY000): View 'xxx' references invalid table(s) or column(s) 或类似提示。
原因很实在：视图要能被反复复用、被 JOIN、被嵌套，而 LIMIT 是终端行为——它截断结果集，破坏了集合语义。数据库引擎无法保证带 LIMIT 的视图在后续查询中仍可组合。
- MySQL 8.0+ 和 PostgreSQL 都明确禁止在
CREATE VIEW中使用LIMIT、OFFSET、ORDER BY（除非配合LIMIT，但依然不被允许） - 某些旧版 MySQL（如 5.7）虽可能“容忍”带
LIMIT的视图创建，但调用时行为不可靠，尤其在子查询或连接中，LIMIT可能被忽略或提前生效 - SQLite 是个例外，允许视图含
LIMIT，但这是特例，不能当作通用方案
后端分页该在哪一层加 LIMIT？
答案很明确：**必须在查询视图的外层 SELECT 中加 LIMIT 和 OFFSET，而不是塞进视图定义里。**
比如你有一个汇总用户订单的视图 v_user_summary：
CREATE VIEW v_user_summary AS SELECT u.id, u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name;
要分页查第 2 页、每页 20 条，正确写法是：
SELECT * FROM v_user_summary ORDER BY id LIMIT 20 OFFSET 20;
-
ORDER BY必须显式写在外层，否则LIMIT结果不稳定（尤其是聚合视图，无排序时行序完全不确定） - 视图本身不带排序，所以外层
ORDER BY不会“污染”视图逻辑，只作用于本次查询结果 - 如果你常按某字段排序分页，建议在视图涉及的基表对应列上建索引（如
users.id），否则ORDER BY ... LIMIT会全表扫描
深度分页（OFFSET 很大）时性能崩了怎么办？
当 OFFSET 超过几万，比如 LIMIT 20 OFFSET 100000，MySQL 仍需扫描前 100020 行再丢弃，响应明显变慢——这不是视图的问题，而是 LIMIT/OFFSET 本身的缺陷。
此时应放弃 offset 分页，改用游标（cursor-based）方式，核心是用上次查询的最后一条记录值作为下一页起点：
- 假设你按
id DESC分页，第一页查：SELECT * FROM v_user_summary ORDER BY id DESC LIMIT 20，拿到最小id（比如id = 9876） - 第二页查：
SELECT * FROM v_user_summary WHERE id < 9876 ORDER BY id DESC LIMIT 20 - 这个
WHERE id < ...能走索引，跳过所有前面的行，速度几乎恒定 - 注意：游标分页要求排序字段严格唯一（推荐用主键），否则重复值会导致漏数据或重复
为什么有人坚持想在视图里塞 LIMIT？
常见动机是“想把分页逻辑封装进视图，让业务代码更干净”。但这条路走不通，而且掩盖了真正问题：
视图是数据抽象层，不是接口契约层。分页参数（当前页、每页数）属于请求上下文，必须由应用层动态传入；硬编码进视图，等于把分页策略固化，丧失灵活性，也违背关注点分离。
真正该封装的是：带条件过滤、关联逻辑、字段裁剪的视图，然后由 API 层决定怎么切片。复杂分页场景下，甚至该用物化临时表或缓存结果，而不是依赖单条 LIMIT 查询。
