视图加WHERE未走索引的根本原因是优化器未将外层条件下推至基表扫描，尤其在含JOIN、GROUP BY或标量函数时；需用EXPLAIN等工具验证执行计划，并确保基表索引字段顺序匹配过滤条件、避免表达式字段、禁用TEMPTABLE算法。
视图里加 WHERE 条件为什么没走索引？
根本原因不是视图本身的问题，而是数据库优化器没把外层 WHERE 下推到基表扫描阶段——尤其当视图含 JOIN、GROUP BY 或标量函数时，优化器常放弃下推。
实操建议：
- 用
EXPLAIN（MySQL/PostgreSQL）或SET STATISTICS XML ON（SQL Server）确认执行计划里WHERE是否出现在基表节点上，而不是最后的“Filter”操作符 - 避免在视图定义中用
SELECT *，显式列出字段并确保关键过滤字段（如user_id、created_at）在基表中已有索引 - 若视图含聚合，但查询只查单条记录，优先改写为子查询或 CTE，让优化器有机会提前剪枝
CREATE VIEW 时怎么让索引真正生效？
视图不存数据，也不直接建索引（除 SQL Server 的“索引视图”外），所谓“视图索引”本质是基表索引能否被复用。关键在字段顺序和谓词匹配。
实操建议：
- 基表索引字段顺序必须匹配视图中最常被
WHERE过滤的列组合，例如视图常查WHERE status = 'active' AND tenant_id = 123，则索引应为(status, tenant_id)而非(tenant_id, status) - 避免在视图字段中用表达式（如
UPPER(name)），否则即使基表有name索引也无法命中；改用计算列 + 索引（SQL Server）或函数索引（PostgreSQL） - MySQL 8.0+ 支持对视图字段加隐藏索引（通过基表），但需确保
ALGORITHM = MERGE（默认），而非TEMPTABLE（会强制物化，索引失效）
视图查询慢，但基表快——十有八九是 TEMPTABLE 模式惹的祸
MySQL 默认对含 DISTINCT、GROUP BY、UNION、子查询等的视图使用 TEMPTABLE 算法，先全量生成临时表再过滤，彻底绕过基表索引。
实操建议：
- 用
SHOW CREATE VIEW view_name查看实际算法；若显示ALGORITHM=TEMPTABLE，就得重构视图逻辑 - 把聚合逻辑下移到应用层或用物化表替代，或者拆成两层：基础视图（仅
ALGORITHM=MERGE）+ 外层查询带GROUP BY - PostgreSQL 没有此限制，但要注意视图里用
LATERAL或窗口函数仍可能阻止下推，需结合EXPLAIN (ANALYZE, BUFFERS)验证
覆盖索引能救视图查询，但得手动配齐字段
视图查询慢的常见场景是回表：索引能定位行，但要读取其他字段还得去聚簇索引捞数据。覆盖索引把所有 SELECT 字段都塞进索引，一次搞定。
实操建议：
- 从视图的
SELECT列表出发，把所有字段（包括WHERE和ORDER BY用到的）全加进一个联合索引，顺序按“等值过滤 > 排序 > 查询输出”排列 - 别迷信“越多越好”——宽索引增大写开销，且 MySQL 单索引最多 16 列，PostgreSQL 页大小限制也实际约束列数
- SQL Server 视图可建唯一聚集索引（即“索引视图”），但要求严格：必须
SCHEMABINDING、所有表用两段名、禁用GETDATE()等非确定函数
最易被忽略的是：视图嵌套层级。三层视图套用后，优化器大概率放弃下推和索引选择——这种时候，别调优，直接扁平化重写查询。
