根本原因是视图展开后触发无索引驱动的嵌套循环，外层每行引发内层全表扫描，导致10万×10万次匹配；关键在于连接字段无索引、函数/隐式转换使索引失效、低选择性谓词及统计信息过期。
根本原因不是“用了视图”，而是视图展开后触发了无索引驱动的嵌套循环（Nested Loops），外层每返回一行，内层就全表扫描一次——10万 × 10万 = 100亿次匹配，全压在CPU上做逐行比较。
视图展开后执行计划退化为 Nested Loops
SQL Server/MySQL/PostgreSQL 在优化视图时，默认会将视图定义内联展开（inline expansion），不生成物化中间结果。一旦视图里含 JOIN 或子查询，且外层主表过滤弱（如没加 WHERE）、内层连接字段无索引，优化器极易选错路径，硬上 Nested Loops。
- 典型表现：
EXPLAIN或图形执行计划中看到内表访问类型是Clustered Index Scan（SQL Server）、Seq Scan（PostgreSQL）、ALL（MySQL） - 关键信号：外层估算
rows=50000，内层rows=80000，但执行计划里该 Nested Loop 节点的Actual Rows高达 40 亿（50000 × 80000） - 注意：即使视图定义简单（如
SELECT a.id, b.name FROM t1 a JOIN t2 b ON a.fk = b.id），只要t2.id没索引，照样崩
视图里用函数或隐式转换导致索引失效
视图定义中若对连接字段或过滤字段做了计算，比如 UPPER(name)、CAST(code AS CHAR)、DATE(created_at)，会导致对应字段无法走索引，内层被迫全扫。
- 常见写法陷阱：
ON UPPER(v1.email) = UPPER(v2.email)—— 两边都函数化，索引完全失效 - 类型不匹配更隐蔽：
JOIN users u ON o.user_code = u.code_str，其中user_code是INT，code_str是VARCHAR，触发逐行隐式转换 - 视图里写
WHERE status IN ('active', 'pending')看似安全，但如果status列选择性极低（重复值占比 >99%），单列索引几乎无效，优化器仍可能跳过它
如何验证和修复视图引发的嵌套循环
别改视图名字或加 SCHEMABINDING，先确认是不是它真在“烧 CPU”：
- 用
sys.dm_exec_query_stats找出高cpu_time的查询，TEXT字段里搜视图名，确认是否命中 - 对视图查询跑
EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或SET STATISTICS PROFILE ON（SQL Server），重点看内表节点的Buffers或Logical Reads是否异常高 - 临时把视图替换成等价的显式 SQL（复制视图定义 + 外层查询条件），手动加
INNER JOIN并指定驱动顺序，观察执行计划是否切换成Hash Join - 建索引前必须验证三点：
status字段是否用于等值匹配（不是LIKE或>）、选择性是否 ≥1%（COUNT(DISTINCT status)/COUNT(*)）、是否需要覆盖查询列（比如视图 SELECT 了id, name, email，那就建(status, id, name, email)联合索引）
真正卡住人的地方，往往不是“不知道要加索引”，而是加了索引后执行计划仍不走——因为视图里藏着一个没注意到的函数调用，或者统计信息过期导致优化器误判行数。每次改完记得 UPDATE STATISTICS 或 ANALYZE table，再重看执行计划。
