视图查询没走索引，根本原因在于展开后的实际SQL未命中基表索引：函数使用、类型不匹配、含GROUP BY/DISTINCT/子查询导致TEMPTABLE物化、计算列过滤或ALGORITHM=TEMPTABLE强制绕过索引。
视图查询没走索引，不是视图“坏了”，而是它展开后的实际 SQL 没命中基表索引——问题出在基表上，不在视图定义本身。
为什么EXPLAIN显示key为NULL或type=ALL
这是最直接的信号：优化器根本没选任何索引。常见原因包括：
- 视图里对索引列用了函数，比如
WHERE UPPER(name) = 'ABC'，哪怕name上有索引也失效；应改用表达式索引（如CREATE INDEX idx_upper_name ON users(UPPER(name))）或改写条件 -
JOIN字段类型不一致，例如t1.user_id INTvst2.user_id VARCHAR，触发隐式转换，索引被跳过 - 视图定义含
GROUP BY、DISTINCT、UNION或子查询，导致优化器物化结果（生成临时表），后续过滤无法下推到基表 - 外层查询加了
WHERE，但该条件字段在视图定义中是计算列（如COALESCE(status, 'unknown')），而基表原始列才有索引
MySQL里ALGORITHM=TEMPTABLE让索引彻底失效
MySQL 对复杂视图默认用TEMPTABLE算法，先全量计算视图结果再过滤，绕过所有基表索引。
- 用
SHOW CREATE VIEW view_name查实际算法；若返回ALGORITHM=TEMPTABLE，就得重构 - 避免在视图里写
SELECT *、LIMIT、ORDER BY（除非外层也带LIMIT且排序字段有索引） - 把聚合逻辑拆出去，或改用内联写法：
(SELECT ... FROM base_table WHERE ...) AS v，保持ON和WHERE裸露在外层
PostgreSQL中物化节点暴露下推失败
执行EXPLAIN (ANALYZE, VERBOSE)时看到MATERIALIZED节点，说明视图被当成中间结果缓存，索引无法参与连接或过滤。
- 高频查询且逻辑固定，优先考虑物化视图：
CREATE MATERIALIZED VIEW mv_orders AS SELECT ...，再对它建索引 - 但注意：
REFRESH MATERIALIZED VIEW会锁表，加CONCURRENTLY需先建唯一索引 - 更轻量的解法是直接在基表建表达式索引，比如视图里用
email LIKE '%@gmail.com'，就建CREATE INDEX idx_email_gin ON users USING GIN(email gin_trgm_ops)
SQL Server索引视图的6个硬性前提常被漏掉
想给视图加聚集索引？必须同时满足全部条件，缺一不可：
- 创建视图时带
WITH SCHEMABINDING，且所有对象引用必须用两段式名称（如dbo.Orders） - 当前会话
SET ANSI_NULLS ON、SET QUOTED_IDENTIFIER ON等6项必须为ON（NUMERIC_ROUNDABORT必须为OFF） - 视图不能含
DISTINCT、TOP、*、GETDATE()等非确定性元素 - 基表统计信息要更新：
UPDATE STATISTICS dbo.Orders WITH FULLSCAN，否则优化器可能误判而弃用索引
真正容易被忽略的是：即使你把所有条件都配齐了，只要外部查询带参数（如WHERE id = @pid）且参数类型和基表列不一致（@pid是INT，列是BIGINT），照样触发隐式转换，索引失效——这个坑藏在调用侧，不在视图里。
