视图查询不走索引而原表能走，是因为视图未被优化器合并，退化为物化临时表导致索引失效；常见原因包括含group by、distinct、聚合函数、子查询、union、order by或limit等阻碍合并的语法。
视图查询不走索引，但原表能走？可能是视图未被合并
MySQL 和 PostgreSQL 在某些条件下会把视图“展开”成底层查询（即视图合并），从而复用原表的索引；但一旦触发无法合并的条件，就会退化为物化（临时结果集），索引失效。这不是 bug，是优化器对语义安全的保守选择。
-
GROUP BY、DISTINCT、聚合函数（如COUNT()、SUM()）出现在视图定义中，基本阻止合并 - 视图含子查询（尤其是相关子查询）或
UNION，多数引擎放弃合并 - MySQL 8.0+ 默认开启
derived_merge=ON，但若视图含ORDER BY或LIMIT，该开关自动失效 - PostgreSQL 的视图默认不物化，但加了
MATERIALIZED关键字就彻底绕过合并逻辑
如何确认视图是否被合并？看执行计划里的 select_type
关键不是有没有用索引，而是执行计划里是否还保留 DERIVED 或 MATERIALIZED 类型——这说明优化器把它当成了独立中间表处理。
- MySQL 中：用
EXPLAIN FORMAT=TREE最直观，看到-> Materialize就是没合并；-> Table scan on <derived></derived>同理 - PostgreSQL 中：
EXPLAIN输出若出现Subquery Scan节点，且其子节点是Seq Scan而非Index Scan，大概率视图未内联 - SQL Server 中注意
SELECT TYPE列是否为VIRTUAL（合并）还是VIEW（未合并）
CREATE VIEW ... WITH CHECK OPTION 会强制禁用合并吗？
不会直接禁用，但间接提高合并失败概率。因为 CHECK OPTION 要求所有 DML 满足视图谓词，优化器为保证语义正确性，倾向保守处理——尤其在涉及多表连接 + 条件过滤时，容易放弃合并以避免误删/误改。
- 简单单表视图加
WITH CHECK OPTION通常不影响合并 - 连接视图（
JOIN多于一张表）+CHECK OPTION→ MySQL 5.7 常退化为DERIVED，8.0 有改善但不保证 - 如果你发现加了
CHECK OPTION后执行变慢，先检查EXPLAIN是否多了一层嵌套
想强制合并？别依赖提示，改写视图定义更可靠
没有跨数据库通用的 /*+ MERGE() */ 提示；Oracle 有，但 MySQL、PostgreSQL 不支持。强行加 hint 可能被忽略，甚至报错。
- 优先移除视图定义中阻碍合并的成分：比如把
SELECT DISTINCT改成应用层去重 - 避免在视图里写
WHERE条件，改由外部查询传入参数（如用WHERE t.status = ?而非视图里写死WHERE status = 'active'） - MySQL 下可临时关闭
derived_merge测试对比：SET SESSION optimizer_switch='derived_merge=off';，但仅用于诊断，勿上线
真正难的不是看出没合并，而是判断哪部分逻辑导致它无法合并——有时候一个看似无害的 COALESCE(col, '') 都会让 MySQL 放弃合并，因为涉及表达式计算，优化器不敢保证等价性。
