如何优化SQL视图定义中的大量JOIN？

SQL Server 中视图嵌套 JOIN 导致性能严重下降，根本原因在于外层 WHERE 条件无法下推至视图内部。许多开发者认为视图能简化查询，但实际上视图会先完整计算整个数据集，再与外部 JOIN 和过滤条件进行本地组装——视图沦为数据搬运工，而非逻辑封装体。要解决此问题，可在视图内部添加过滤条件、剔除大字段、使用 WITH 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），它支持参数且能被优化器展开，许多团队最终选择此方案。