sql server视图join易致性能骤降，因外层条件不自动下推；应显式过滤、避免select*、用索引视图+schemabinding、on中写join条件、远程查询用openquery并查执行计划。
直接在视图上做 JOIN 很容易踩坑——SQL Server 默认不会把外层 JOIN 条件下推到视图内部，结果就是先拉全量视图数据，再本地关联，性能断崖式下跌。
别让视图变成“黑箱”，必须控制它的输出边界
视图本身不存储数据，但查询优化器对它的处理很保守。如果你写 SELECT * FROM v_customer_orders INNER JOIN products ON ...，SQL Server 通常不会把 products 的过滤条件或连接逻辑“塞进”v_customer_orders 的定义里执行。
- 视图定义中必须显式写出
WHERE过滤（比如限定Country = 'China'），不能依赖外层 WHERE - 避免在视图里用
SELECT *，只选真正需要的列；大字段（TEXT、NVARCHAR(MAX)、XML）会显著拖慢序列化和网络传输 - 如果视图基于远程表（linked server），更要确保它已封装好连接和裁剪逻辑，否则
INNER JOIN会触发全量拉取
用 WITH SCHEMABINDING + 索引视图固化执行路径
普通视图只是保存 SQL 文本，而带 WITH SCHEMABINDING 的索引视图会被 SQL Server 当作物化结构对待，JOIN 时更可能复用其预计算结构，尤其适合高频关联场景。
- 创建前确保所有引用表名都用两段式（
schema.table），且用户有VIEW DEFINITION权限 - 必须在视图上建唯一聚集索引（
CREATE UNIQUE CLUSTERED INDEX），否则不生效 - 注意限制：不能含
GETDATE()、子查询、OUTER JOIN、聚合函数（除非配GROUP BY和COUNT_BIG(*)）
外层 JOIN 条件别写在 WHERE，优先挪到 ON 里
这是最容易被忽略的语义陷阱。比如 v_orders LEFT JOIN customers ON v_orders.CustomerID = customers.ID WHERE customers.Country = 'US'，实际等价于 INNER JOIN，且过滤发生在 JOIN 之后——视图数据已全拉回来了。
- 想保留视图全部行？把条件放进
ON：v_orders LEFT JOIN customers ON v_orders.CustomerID = customers.ID AND customers.Country = 'US' - 想提前过滤视图内容？别靠外层 WHERE，改写视图定义或加参数化内联表值函数（
ITVF） - 用
EXISTS替代LEFT JOIN ... IS NULL判断缺失时，执行计划往往更干净
远程视图 + OPENQUERY 是唯一可靠的下推手段
当视图跨服务器（linked server），仅靠视图定义无法保证下推。SQL Server 仍可能把整个视图结果集拉到本地再 JOIN。此时必须用 OPENQUERY 手动拼接完整远程查询。
- 示例：
SELECT * FROM OPENQUERY(remote_srv, 'SELECT o.OrderID, c.CompanyName FROM Orders o JOIN Customers c ON o.CustomerID = c.CustomerID WHERE c.Country = ''China''') -
OPENQUERY的字符串是原样发给远程服务器执行的，不经过本地优化器，所以 WHERE、JOIN、列投影全在远端完成 - 缺点：无法参数化（需动态 SQL）、调试困难、权限链更长；务必确认远程服务器支持对应语法
最麻烦的不是语法写不对，而是你以为视图“应该”被优化，结果执行计划里赫然出现 Remote Query → Nested Loops → Table Scan —— 那说明所有优化都落空了。每次改完视图或外层 JOIN，务必看 Execution Plan 里的 Actual Rows 和 Remote Query 节点。
