视图查询变慢往往因未走索引，主因是MySQL 5.7及之前默认TEMPTABLE算法导致物化全表、条件无法下推；MySQL 8.0+需用MERGE算法并满足条件才能下推WHERE触发索引，SQL Server需SCHEMABINDING保障统计准确，PostgreSQL则须避免OFFSET、窗口函数等阻断展开。
视图查询变慢，是不是没走索引？
不是所有视图都“自动优化”。PostgreSQL 和 SQL Server 会尝试视图展开（view expansion），但 MySQL 8.0 之前默认不展开，SELECT * 从视图查数据时，可能先物化整个视图结果再过滤，导致全表扫描——哪怕 WHERE 条件字段明明有索引。
- MySQL 5.7 及更早版本：视图默认是
TEMPTABLE算法，相当于先CREATE TEMPORARY TABLE存下全部结果，再执行外层WHERE，索引完全失效 - MySQL 8.0+ 支持
MERGE算法（需视图定义满足条件），才可能把外层条件下推到基表，触发索引 - 用
EXPLAIN看执行计划，如果type是ALL或rows高得离谱，大概率卡在物化阶段
怎么强制让视图用上索引？
别依赖视图自动优化，主动控制下推逻辑。核心思路是：让数据库能“看见”基表的过滤条件，而不是在视图壳子里兜圈子。
- 避免在视图定义里写
WHERE或GROUP BY—— 这些会阻碍外层条件下推；视图尽量只做SELECT ... FROM t1 JOIN t2这类纯结构映射 - MySQL 中显式指定算法：
CREATE ALGORITHM = MERGE VIEW v AS SELECT id, name FROM users - SQL Server 要留意
SCHEMABINDING：加了它才能保证统计信息准确，优化器才敢下推；不加可能导致估算行数严重偏差 - PostgreSQL 没有算法选项，但要避开
OFFSET、窗口函数或不可下推表达式（如COALESCE(col, 'default')），否则视图展开会中止
嵌套视图为什么越查越慢？
每多一层视图，就多一次逻辑重写和估算误差叠加。三层视图嵌套后，PostgreSQL 可能放弃展开，SQL Server 容易生成低效嵌套循环，MySQL 直接退化成多次临时表拼接。
- 用
pg_get_viewdef('v3')（PostgreSQL）或sp_helptext 'v3'（SQL Server）展开看最终 SQL，确认有没有意外引入DISTINCT、ORDER BY或标量子查询 - 嵌套超过两层，建议把中间结果物化为普通表 + 索引，尤其当某层视图固定用于高频查询时
- SQL Server 中，
WITH SCHEMABINDING视图可被当成“索引视图”建唯一聚集索引，但要求严格：必须确定性函数、无GETDATE()、基表要有主键等
视图性能问题现场怎么快速定位？
别猜，直接对比执行计划。同一查询，分别跑“从视图查”和“把视图 SQL 拷出来手写查”，看 rows、key_len、Extra 字段差异。
- MySQL 中重点关注
Extra是否出现Using temporary或Using filesort；如果手写 SQL 没这俩，但视图有，说明视图定义或算法阻断了优化 - PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，比对Actual Total Time和Shared Hit Blocks，差距大就说明缓存没利用好 - SQL Server 注意
Estimated Subtree Cost和实际执行时的Query Plan Hash是否一致；不一致往往意味着参数嗅探失败，而视图加剧了这个问题
复杂点在于：视图本身没问题，但调用它的应用传了低选择性参数（比如 WHERE status = 'pending' 占 95% 行数），这时候再好的展开也救不了——得结合业务语义加覆盖索引，或者干脆不让这类查询走视图。
