MySQL视图不支持分页优化，分页性能取决于原表索引、是否避免OFFSET及是否采用游标分页；视图定义中不可用LIMIT/OFFSET，且JOIN、函数、SELECT*等易导致索引失效或回表。
MySQL视图本身不支持分页优化，必须在查询视图时显式加 LIMIT 和 ORDER BY
视图只是保存的 SELECT 语句，执行时会被展开成底层表查询。它不存储数据、不自动建索引、也不缓存结果。所以 SELECT * FROM my_view LIMIT 10000, 20 依然会扫描前 10000 行——和直接查原表一样慢。
常见错误是以为“建个视图就能让分页变快”，其实视图没这个能力。真正起作用的是：原表是否有合适的索引 + 外层查询是否能走索引覆盖 + 是否避免 OFFSET 跳过大量行。
- 视图定义里不能写
LIMIT或OFFSET（语法报错） - 如果视图含
GROUP BY、DISTINCT、子查询或聚合函数，分页更易触发临时表和文件排序 - 用
EXPLAIN看执行计划时，要盯紧type（是否为range/ref）、key（是否命中索引）、Extra（是否出现Using filesort或Using temporary）
分页必须依赖主键/有序索引字段，而非 OFFSET
大数据量下 LIMIT 100000, 20 的性能崩塌，本质是 MySQL 还得从头扫出 100000 行再丢弃。换成基于游标的分页（cursor-based pagination），效率立竿见影。
假设视图基于一张有自增主键 id 的订单表，且你按 id DESC 分页：
SELECT * FROM my_view WHERE id <p>这比 <code>LIMIT 100000, 20</code> 快一个数量级，前提是 <code>id</code> 上有索引（主键天然满足）。</p>
- 视图字段必须包含用于游标判断的索引列（如
id、created_at），否则无法下推条件 - 如果视图用了
JOIN，确保游标字段来自驱动表，且关联字段也有索引 - 不要在视图里用
UUID或无序字段做分页依据——会导致索引失效或随机 I/O
索引覆盖能避免回表，但视图字段必须严格匹配索引列顺序
覆盖索引要求查询的所有字段（包括 SELECT 列和 WHERE/ORDER BY 中的字段）都落在同一个复合索引里。视图的 SELECT 列一旦超出索引范围，就会触发回表——哪怕只多一个 TEXT 字段。
例如，视图定义为：SELECT id, user_id, status, created_at FROM orders，你想按 user_id 分页查最近 20 条：
SELECT * FROM my_view WHERE user_id = 888 ORDER BY created_at DESC LIMIT 20;
这时最优索引是：INDEX idx_user_created (user_id, created_at, id)。注意顺序：WHERE 字段在前，ORDER BY 次之，最后补上 SELECT 中需要但未出现在前两者的列（这里是 id）。
- 视图里若包含
CONCAT()、CASE、函数计算字段，这些无法被索引覆盖，会强制回表 -
SELECT *是索引覆盖杀手——视图定义里有多少字段，就得把它们全塞进索引，成本极高 - 用
EXPLAIN FORMAT=JSON查看covering_index_used字段，确认是否真走覆盖
视图 + 分页的典型陷阱：JOIN 导致索引失效或重复数据
带 JOIN 的视图分页，最容易在两个地方翻车：一是关联字段没索引，导致嵌套循环全表扫描；二是一对多关系引发重复行，使 LIMIT 截断逻辑错乱（比如本该取第 100–119 条订单，结果因用户信息重复，实际拿到的是第 100–119 条“订单-用户组合”）。
例如视图连了 orders 和 users，但只按 orders.id 分页：
- 确保
users.id和orders.user_id都有索引，且类型一致（避免隐式转换） - 如果业务只要订单数据，别在视图里
SELECT users.name——把它移出视图，用应用层二次查询补全 - 测试时用
SELECT COUNT(*)对比视图和原表结果行数，不等就说明 JOIN 引入了笛卡尔积或 NULL 匹配问题
复杂视图分页不是加个索引就能解决的事，关键在拆解：先保证单表分页高效，再谨慎叠加关联，每一步都要用 EXPLAIN 验证执行路径。索引设计不是越宽越好，而是刚好够用、顺序合理、避免冗余。
