视图分页性能差因查询需全量执行再裁剪，LIMIT OFFSET 无法提前终止；索引难复用、游标失效、排序不可靠，应下沉分页到底层表或改用物化表。
因为视图本身不存储数据，每次查询都要展开并执行完整逻辑，再叠加 LIMIT 的偏移跳过机制，导致数据库被迫处理远超返回行数的中间结果。
视图展开后实际执行的 SQL 比你写的长得多
MySQL（以及多数关系型数据库）在遇到视图时，会把视图定义里的 SELECT 语句“内联展开”到外层查询中。如果你的视图包含 JOIN、GROUP BY、子查询或窗口函数，那最终执行的语句可能变成几十行嵌套结构。而 LIMIT OFFSET 是最后一步裁剪，数据库必须先完成所有关联、聚合、排序，才能开始丢弃前 N 行。
常见错误现象：
- 视图里
ORDER BY被忽略，导致外层加LIMIT时结果不可控 - 视图用了
DISTINCT或GROUP BY，但没加索引，LIMIT 100000, 20实际要先算出全部分组结果再截断 - EXPLAIN 显示
type: ALL或rows高得离谱，说明视图展开后根本没走索引
为什么加了索引也没用？
视图不是表，不能直接建索引。即使底层表有索引，一旦视图引入了计算列、函数、表达式或跨表连接，优化器就很难复用原有索引。尤其是以下情况：
-
SELECT CONCAT(name, '-', id) AS full_id FROM users→ 无法用name或id索引加速排序 -
WHERE status IN (SELECT code FROM config WHERE category = 'order')→ 子查询可能阻止索引下推 - 视图中
ORDER BY create_time DESC，但外层又加了LIMIT 50000, 10→ 数据库仍需扫描并排序全部匹配行，才能跳过前 5 万
参数差异：视图定义里带 ORDER BY 且没加 SQL SECURITY DEFINER，可能导致权限检查开销额外增加；而用 ALGORITHM=TEMPTABLE 创建的视图，每次查询都会生成临时表，LIMIT 完全无法提前终止流程。
游标分页在视图上基本失效
游标分页依赖稳定、唯一、可比较的排序键（如 create_time, id），但视图常因以下原因破坏这个前提：
- 聚合后丢失原始主键，无法用
id做精确锚点 -
LEFT JOIN引入 NULL 值，导致WHERE cursor_col > ?条件漏数据 - 视图里用了
UNION ALL，不同子查询的排序字段类型不一致（比如一个用DATETIME，另一个用TIMESTAMP），造成隐式转换和索引失效
性能影响明显：一个本可在毫秒级返回的视图分页，在偏移量超过 10 万后，响应时间可能从 50ms 涨到 3s+，且 CPU 和临时表空间占用陡增。
能直接用的绕过方案
别让视图承担分页逻辑，把分页下沉到底层表。例如：
- 视图只做轻量字段映射（
SELECT id, name, status FROM users），分页逻辑由应用层用id范围控制 - 需要复杂逻辑时，改用物化思路：用定时任务把视图结果写入一张带主键的
summary_table，再对这张表分页 - 实在要用视图 + 分页，强制指定排序字段为底层表主键，并在
WHERE中补上主键范围条件：WHERE t1.id BETWEEN ? AND ?，避免全视图扫描
最容易被忽略的一点：视图的 CREATE VIEW 语句里如果写了 ORDER BY，MySQL 会忽略它——除非外层也写 ORDER BY，否则排序行为完全不确定。这意味着你以为的“有序视图”，在加 LIMIT 后可能每次返回不同数据。
