视图本身不决定是否走主键索引，是否触发全表扫描取决于外层where条件能否下推至基表、视图定义是否含group by/distinct/聚合等阻断下推的操作，以及底层索引结构和优化器决策。
视图本身不决定是否走主键索引
SQL 视图只是保存的 SELECT 语句定义，它不存储数据，也不直接控制执行计划。是否触发全表扫描，取决于查询视图时的 WHERE 条件、底层表的索引结构，以及优化器能否将外层条件“下推”到视图定义中。很多开发者误以为“建了视图就能用上索引”，结果一查执行计划发现 EXPLAIN 显示 type: ALL —— 这不是视图的问题，是查询没带可下推的过滤条件。
确保 WHERE 条件能下推到基表主键字段
MySQL 和 PostgreSQL 都支持条件下推（predicate pushdown），但前提是视图定义里不能有阻断下推的操作。常见破坏下推的行为包括：
- 视图中用了
GROUP BY、DISTINCT、窗口函数或聚合（如COUNT()），会导致外层WHERE无法穿透到原表 - 视图定义含子查询（尤其相关子查询），优化器常放弃下推
- 对主键字段做了函数操作，比如
WHERE YEAR(created_at) = 2024，即使created_at有索引也失效 - 视图 SELECT 列中重命名了主键字段（如
id AS user_id），而外层查询却用WHERE user_id = 123—— 某些旧版本 MySQL 无法识别别名与原始索引列的映射
正确写法示例（假设基表 users 主键为 id）：
CREATE VIEW active_users AS SELECT id, name, email FROM users WHERE status = 'active';
之后查询 SELECT * FROM active_users WHERE id = 456; 很可能命中 PRIMARY 索引 —— 因为 id 是原始主键，且无任何包装操作。
避免在视图中 JOIN 多张大表后只查其中一张的主键
如果视图定义是 SELECT u.id, u.name, o.order_no FROM users u JOIN orders o ON u.id = o.user_id，那么即使你只执行 SELECT id FROM user_orders_view WHERE id = 123，优化器也可能先做 JOIN 再过滤，导致全表扫描 orders。原因在于：JOIN 后的行集已丢失原始单表的索引边界。
更安全的做法是分层设计：
- 为高频单表查询单独建轻量视图（只
SELECT本表字段 + 简单WHERE） - 需要关联的场景，改用带参数的内联表值函数（PostgreSQL 的
FUNCTION/ MySQL 8.0+ 的LATERAL子查询），让主键条件在 JOIN 前就生效 - 若必须用视图，确保所有 JOIN 条件都包含索引字段，且外层
WHERE至少命中其中一张表的主键或唯一索引
用 EXPLAIN 验证视图查询是否走主键索引
不要依赖“看起来合理”，必须实测。对视图执行 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）看实际执行路径：
- 关注
key字段是否显示PRIMARY或对应主键名 - 检查
rows是否接近你要查的单行（比如rows: 1），而非几万行 - 留意是否有
Using temporary或Using filesort—— 这些往往是下推失败的信号 - 在 MySQL 中，如果
Extra出现Using where; Using index，说明走了覆盖索引；若只有Using where，则大概率发生了回表甚至全扫
一个容易被忽略的细节：某些 ORM（如 Django 的 .extra() 或 SQLAlchemy 的 select_from()）生成的 SQL 可能给视图加了无意义的 ORDER BY NULL 或 LIMIT，干扰优化器选择索引。务必检查最终下发的 SQL，而不是 ORM 调用链。
