SQL Server 中视图嵌套 JOIN 导致性能急剧下降，根本原因在于外层 WHERE 条件无法被下推至视图内部。许多开发者以为视图能简化查询逻辑，实际上它会让整个数据集先被完整计算一次，再与外部 JOIN 和过滤操作进行“本地组装”——视图变成了数据搬运工，而非逻辑封装体。解决方案包括：在视图内显式添加过滤条件、剔除大字段、使用 SCHEMABINDING 创建索引视图、或借助 OPENQUERY 强制下推。如果这些方法都不适用，可改用参数化的内联表值函数（ITVF），一劳永逸地解决性能瓶颈。
视图嵌套 JOIN 为何会引发性能问题？
这是因为 SQL Server 默认不会将外部查询条件“下推”到视图内部。例如，执行 SELECT * FROM v_orders_with_customer INNER JOIN products ON ... WHERE products.category = 'phone' 时，优化器大概率会先完整执行视图 v_orders_with_customer（可能包含百万行数据），然后在本地进行 JOIN 和过滤——视图沦为数据搬运工，而非逻辑封装体。本质上，视图只是一个 SQL 文本快照，不具备运行时的数据裁剪能力。
必须在视图定义中显式写入 WHERE，不能依赖调用方过滤
视图并非函数，既无参数也无运行时裁剪能力。外层的 WHERE 条件对它几乎无效，尤其当视图引用远程表或包含聚合操作时更是如此。
- 错误写法：
CREATE VIEW v_orders AS SELECT * FROM orders（未做过滤、未限制列） - 正确做法：在视图内部限定业务范围，例如
WHERE status IN ('shipped', 'delivered')、AND create_time >= DATEADD(day, -30, GETDATE()) - 大字段（
NVARCHAR(MAX)、XML、TEXT）必须排除，它们会拖慢序列化和网络传输，即使最终未使用到
关键点在于：视图定义越“干净”，外层查询遭受的性能损失就越小。
使用 WITH SCHEMABINDING + 索引视图固化执行路径
普通视图只是 SQL 文本快照，而索引视图会被 SQL Server 当作物化结构处理，JOIN 时更倾向于复用预计算结果。
- 创建前必须使用两段式引用：
dbo.orders，不能只写orders - 必须添加
WITH SCHEMABINDING，否则无法建立索引 - 硬性要求是创建唯一聚集索引：
CREATE UNIQUE CLUSTERED INDEX IX_v_orders ON v_orders (order_id) - 限制非常严格：不能包含
GETDATE()、子查询、OUTER JOIN、聚合函数（除非搭配GROUP BY和COUNT_BIG(*)）
索引视图的约束虽然死板，但只要能用，性能提升立竿见影。
远程视图 JOIN 时，OPENQUERY 是唯一可靠的下推手段
跨服务器（linked server）场景下，SQL Server 极大概率将整个视图结果拉到本地再 JOIN，即使视图内部写了 WHERE 也无济于事。此时 OPENQUERY 是绕过优化器保守策略的强制手段。
- 不应写成：
SELECT * FROM v_remote_orders JOIN local_customers ... - 应当写成：
SELECT * FROM OPENQUERY(remote_srv, 'SELECT o.id, o.total FROM orders o WHERE o.status = ''shipped''') o JOIN local_customers c ON o.id = c.order_id - 注意单引号需双写，SQL 字符串中不能出现未转义的
' - 每次修改远程查询逻辑，必须同步更新
OPENQUERY中的字符串，维护成本较高但效果确定
复杂之处在于：索引视图的约束过于苛刻，而 OPENQUERY 又无法参数化。若要兼顾灵活性与性能，需要退一步——放弃视图，改用内联表值函数（ITVF），它支持参数并能被优化器展开，这正是许多开发团队最终的选择。
