视图查询没走索引，根本原因在于展开后的实际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 INT vs t2.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），照样触发隐式转换，索引失效——这个坑藏在调用侧，不在视图里。