SQL Server 视图支持有限嵌套（建议≤3层），禁止循环引用；跨库引用需四部分命名并确保权限完整；索引视图仅允许引用其他索引视图，且依赖链改动会导致隐式性能退化。
SQL Server 中视图可以引用其他视图，但不是无限制嵌套
能，但必须清楚：SQL Server 允许视图引用另一个视图（即“嵌套视图”），但不支持无限层级或循环依赖。数据库引擎在解析时会递归展开所有被引用的视图，最终生成一个等效的扁平化查询。一旦出现 view A → view B → view A 这类循环引用，CREATE VIEW 或 ALTER VIEW 会直接报错：Msg 250, Level 16, State 1: Cannot create view because it references itself.
常见错误现象包括：
- 修改底层视图后，上层视图返回过期/错误数据（尤其在未执行
sp_refreshview时） - 执行
SELECT * FROM upper_view报错，但把该视图定义里的 SQL 拿出来单独跑却正常 - 查询计划中出现大量嵌套的
Compute Scalar或重复 JOIN，性能陡降
嵌套超过 3 层就该警惕性能与可维护性问题
SQL Server 官方文档未硬性限制嵌套深度，但实践中建议控制在 3 层以内。每多一层嵌套，优化器就要多做一次逻辑树展开和绑定检查，且无法对中间视图做索引（除非是索引视图，而索引视图本身禁止引用非索引视图）。
使用场景里容易踩坑的是报表类系统：比如 sales_summary_vw 引用 order_detail_vw，后者又引用 customer_segment_vw，而这个再依赖 geo_region_vw —— 四层嵌套后，哪怕只改最底层城市表的列名，所有上层视图都可能失效，且 sys.dm_exec_describe_first_result_set 可能返回不一致的元数据。
实操建议：
- 用
sys.dm_exec_describe_first_result_set(N'SELECT * FROM your_view', NULL, 0)检查嵌套后最终列结构是否符合预期 - 定期运行
EXEC sp_msforeachtable 'IF OBJECTPROPERTY(OBJECT_ID(''?''), ''IsView'') = 1 EXEC sp_refreshview ''?'''（慎用于生产） - 避免在嵌套视图中使用
TOP、OFFSET/FETCH或FOR XML，否则上层视图可能因排序缺失报错
跨数据库引用视图时，权限与解析路径必须显式写全
视图引用另一个数据库中的视图，语法上没问题，但必须用四部分命名法：database_name.schema_name.view_name。漏掉 schema_name（如只写 OtherDB..MyView）会导致运行时报错：Invalid object name 'OtherDB..MyView'，因为 SQL Server 默认查找 dbo 架构，而目标视图可能在 reporting 或 app 下。
权限方面，调用方用户需同时满足：
- 对当前数据库有
VIEW DEFINITION权限（才能读取视图定义） - 对目标数据库有
SELECT权限（不只是目标视图，还要能访问它所依赖的所有基表或下层视图） - 若目标视图用了函数或 CLR，还需额外授权
EXECUTE
一个典型失败案例：GRANT SELECT ON dbo.vw_sales TO app_user 看似够了，但如果 vw_sales 内部引用了 FinanceDB.dbo.vw_revenue_by_month，而 app_user 在 FinanceDB 中没有 SELECT 权限，查询仍会失败，错误信息却是模糊的：The SELECT permission was denied on the object 'vw_revenue_by_month', database 'FinanceDB', schema 'dbo'.
索引视图不允许引用普通视图，这是硬性限制
如果你打算给某个视图加唯一聚集索引（即创建索引视图），那它里面所有被引用的对象——无论是表还是视图——都必须是索引视图，且所有表都得带架构前缀（如 dbo.orders），不能用 *，也不能含不确定函数（如 GETDATE()、NEWID()）。
换句话说：CREATE VIEW indexed_vw WITH SCHEMABINDING AS SELECT ... FROM dbo.base_table JOIN other_db.dbo.another_indexed_vw 是合法的；但只要其中任意一环是普通视图（没建唯一聚集索引），整个语句就会失败，报错：Cannot create index on view 'indexed_vw' because it references view 'plain_vw' which is not an indexed view.
这个限制常被忽略，尤其在从普通视图迁移到索引视图时。更麻烦的是，即使你手动把下层视图也改成索引视图，还得确保它们的 ANSI_NULLS 和 QUOTED_IDENTIFIER 都为 ON，否则连创建都通不过。
复杂点在于：索引视图的依赖链一旦形成，后续任何改动（比如删掉某个被多个索引视图共用的基础索引视图）都会导致所有上层索引自动失效，且不会报错，只是查询计划里不再走索引，性能悄然退化。
