视图不存数据，索引必须建在基表上且查询需满足下推条件；类型不匹配、隐式转换、物化视图、统计信息过期等均会导致索引失效。
SQL视图里用的字段，加了索引也没用？
视图本身不存数据，只是保存 SELECT 语句的定义。所以 CREATE VIEW 里引用的字段，哪怕在底层表上建了 INDEX，查询时是否能走索引，完全取决于最终执行计划里实际访问的是哪张表、用的哪个条件、JOIN 的方式是否支持下推。
常见错误现象：EXPLAIN 显示对视图做全表扫描，但底层表明明有 user_id 索引；或者 JOIN 后过滤变慢，却误以为“视图没索引就优化不了”。
- 视图不改变物理存储，索引必须建在基表（
FROM后的真实表）上，不是建在视图名上 - 如果视图含
DISTINCT、GROUP BY、窗口函数或子查询，优化器常放弃下推条件，导致索引失效 -
WHERE条件必须落在视图定义中「可下推」的列上——通常是基表的原始列，而非计算列（如UPPER(name)）
JOIN 键类型不一致，索引直接被忽略
两个表 JOIN 时，即使两边都对 user_id 建了索引，只要字段类型不严格匹配（比如一边是 INT，另一边是 BIGINT 或 VARCHAR），MySQL/PostgreSQL 都可能放弃使用索引，转为嵌套循环或临时表。
典型错误现象：EXPLAIN 显示 type=ALL 或 Extra: Using join buffer，且 key 列为 NULL。
- 检查
SHOW CREATE TABLE，确认 JOIN 字段的类型、长度、字符集、是否允许 NULL 完全一致 - 避免隐式转换：不要用
ON t1.id = t2.code（id是 INT，code是 VARCHAR） - PostgreSQL 对类型敏感，
TEXT和VARCHAR(255)视为不同类型；MySQL 8.0+ 对utf8mb4_bin和utf8mb4_0900_as_cs排序规则不兼容也会拒用索引
视图 + JOIN 查询慢，先看执行计划里有没有“物化”
某些数据库（如 MySQL 5.7+、PostgreSQL 12+）会对复杂视图自动物化（即把视图结果暂存为临时表），这反而让原本能走索引的 JOIN 变成两阶段扫描——先算视图，再 JOIN，索引彻底失效。
使用场景：视图含聚合、LIMIT、不可下推表达式，又在外层 JOIN 或 WHERE 中引用。
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0）或EXPLAIN (ANALYZE, VERBOSE)（PostgreSQL）确认是否有MATERIALIZED节点 - 强制绕过物化：MySQL 可改写为内联视图（
(SELECT ...) AS v），PostgreSQL 可加NOT MATERIALIZED提示（v12+） - 更稳的做法是拆开——把视图逻辑复制到主查询中，确保 JOIN 键始终裸露在最外层 ON 条件里
为什么给视图字段加索引没反应？
因为 SQL 标准里根本不允许对视图建索引。你看到的 CREATE INDEX ON my_view(...) 要么是语法错误（PostgreSQL 直接报错），要么是某些数据库（如 SQL Server）的“索引视图”特例——但它要求视图定义极其严格（SCHEMABINDING、无非确定函数、所有表加 NOLOCK 等），且只适用于极少数 OLAP 场景。
绝大多数情况下，所谓“给视图加索引”，其实是想加速基于视图的查询，而真正有效的只有两条路：在基表上建合适索引，以及确保查询能穿透视图结构命中这些索引。
- 别信“视图索引”这种模糊说法；查文档确认你用的数据库是否真支持，以及支持到什么程度
- SQL Server 的索引视图会强制把结果固化到磁盘，更新基表时同步维护，代价很高，不适合高并发写场景
- MySQL 和 PostgreSQL 用户请直接放弃这个念头，专注优化基表索引和查询写法
最常被忽略的一点：JOIN 键的统计信息是否准确。如果 ANALYZE TABLE 没跑过，或数据分布突变（比如某 status 值从 5% 占比变成 95%），优化器可能选错执行路径——这时候加索引也白搭。
