SCHEMABINDING 仅锁定视图依赖的基表等对象，不锁定视图自身结构；修改视图需用 ALTER VIEW，但所有引用对象必须用两部分名称（如 dbo.Orders），且被引用函数也须带 SCHEMABINDING，否则绑定静默失效。
不能靠 WITH SCHEMABINDING 锁定视图自身结构，它只锁定视图所依赖的对象（表、函数等）不被意外修改。 想改视图定义？直接 ALTER VIEW 就行——SCHEMABINDING 不拦你。它拦的是别人动你的基表。
创建带 SCHEMABINDING 的视图必须写两部分名称
SQL Server 要求所有被引用对象（表、函数、视图）都显式带上 schema，比如 dbo.Orders，不能只写 Orders。否则语句能执行成功，但视图实际没绑定上——查 sys.views.is_schema_bound 会是 0。
常见错误现象：视图建完，ALTER TABLE dbo.Orders DROP COLUMN OrderDate 居然成功了，说明绑定失败。
- 必须用
CREATE VIEW dbo.vw_xxx WITH SCHEMABINDING AS SELECT id, dbo.fn_calc(x) FROM dbo.t1 - 如果函数
fn_calc自身没加WITH SCHEMABINDING，视图绑定也会静默失效 - 跨 schema 引用（如
sales.Customers）必须完整写出，不能省略sales.
ALTER TABLE 失败时先检查是否触碰了绑定依赖
一旦视图绑定了架构，对基表的某些变更会被直接拒绝，错误信息通常是：Msg 5074, Level 16, State 1: The object 'xxx' is dependent on column 'yyy'.
这不是 bug，是设计行为。典型被拦的操作包括：
-
DROP COLUMN（哪怕列没在视图 SELECT 列表里，只要定义中引用过） -
ALTER COLUMN ... TYPE（类型不兼容，比如INT→VARCHAR） -
ALTER COLUMN ... NULL改为NOT NULL（若视图里该列参与了计算或连接） - 重命名表或列（
sp_rename同样触发依赖检查）
绕开方法只有两个：先 ALTER VIEW 去掉 SCHEMABINDING，或彻底删掉视图。
想建索引视图？SCHEMABINDING 是硬门槛
没有 SCHEMABINDING，CREATE UNIQUE CLUSTERED INDEX 会报错：Msg 1940, Level 16, State 1: Cannot create index on view 'xxx' because it is not schema bound.
除了绑定，索引视图还有几个容易漏的条件：
- SELECT 中不能用
*，必须明确列出每列 - 不能含
UNION、INTERSECT、EXCEPT、子查询（除非是派生表）、聚合（GROUP BY可以，但得配ALL或处理空值） - 所有参与列不能是计算列（除非确定可持久化且有确定性）
- 连接必须是
INNER JOIN，且关联字段需有外键或唯一约束支撑
另外，查询时若想强制走索引视图（避免优化器忽略），得加提示：SELECT * FROM dbo.vw_indexed WITH (NOEXPAND)。
SET 选项不匹配会导致索引视图不可用
即使视图建好了、索引也建成功了，查询时仍可能“视而不见”——因为会话的 SET 选项不符合要求。最常踩的坑是 ARITHABORT OFF（OLE DB/ODBC 默认就是 OFF）。
关键 SET 项必须为 ON： ANSI_NULLS、ANSI_WARNINGS、CONCAT_NULL_YIELDS_NULL、QUOTED_IDENTIFIER；ARITHABORT 必须 ON（尤其从应用连接过来时）；NUMERIC_ROUNDABORT 必须 OFF。
验证方式：在目标会话中运行 SELECT SESSIONPROPERTY('ARITHABORT')，返回 1 才合规。应用层连 SQL Server 前，最好显式执行 SET ARITHABORT ON。
复杂点在于：这些限制不是创建时校验的，而是运行时生效。一个视图在 SSMS 里查得好好的，换到 .NET 应用里就退回到基础表扫描——十有八九是 ARITHABORT 没对齐。
