跨架构迁移视图后查询报“SELECT permission denied”是因为权限未随视图迁移，需手动授予目标架构下视图或架构的SELECT权限，并确保重建时添加WITH SCHEMABINDING且引用对象使用两段式命名，同义词指向变更后也须同步授权目标视图。
视图跨架构迁移后查询报“SELECT permission denied”
直接附加或还原数据库后，原视图能查到，但换到新架构（比如从 dbo 搬到 sales）就报错，典型错误是：Msg 229, Level 14, State 5, Line 1 SELECT permission denied on object 'v_customer_summary', database 'MyDB', schema 'sales'。这不是语法问题，是权限没跟着走。
SQL Server 不会自动把源架构下对视图的 SELECT 权限复制到目标架构——哪怕你用 CREATE VIEW sales.v_customer_summary AS ... 重建了视图，权限也得手动补。
- 先确认当前用户是否有该视图所在架构的
SELECT权限：SELECT has_perms_by_name('sales.v_customer_summary', 'OBJECT', 'SELECT')，返回 0 就说明没权限 - 不要只给
db_datareader角色——它只覆盖dbo架构，默认不作用于其他架构 - 必须显式授权：
GRANT SELECT ON OBJECT::sales.v_customer_summary TO [AppUser] - 如果要批量授权整个架构，用：
GRANT SELECT ON SCHEMA::sales TO [AppUser]，但注意这会开放该架构下所有现有及未来新建对象的读权限
迁移脚本里漏掉 WITH SCHEMABINDING 导致权限失效
有些视图依赖底层表结构，迁移时若没加 WITH SCHEMABINDING，SQL Server 允许你创建成功，但后续执行 GRANT SELECT 会静默失败（不报错，但权限实际没生效），查询时仍提示拒绝访问。
根本原因是：没有绑定的视图，SQL Server 不强制校验调用者对基表的权限；而加了 SCHEMABINDING 后，权限检查链条变长，必须同时满足“对视图有 SELECT”和“对基表有 REFERENCES/SELECT”，否则就拦在门口。
- 检查原视图是否含
WITH SCHEMABINDING：SELECT OBJECTPROPERTY(OBJECT_ID('dbo.v_report'), 'IsSchemaBound')，返回 1 才算启用 - 迁移时重建视图必须带上它：
CREATE VIEW sales.v_report WITH SCHEMABINDING AS SELECT ... - 加完之后，再执行
GRANT SELECT才真正生效；否则权限只挂名，不起作用 - 注意：加
SCHEMABINDING要求所有引用对象（表、列）都用两段式命名，如dbo.Customers.ID，不能只写Customers.ID
同义词（Synonym）指向跨架构视图时权限链断裂
如果业务代码里用了同义词（比如 CREATE SYNONYM v_report FOR dbo.v_report），迁移后改成指向新架构视图（CREATE SYNONYM v_report FOR sales.v_report），但忘了同步更新同义词所有者的权限，就会出现“能查同义词，但查不到数据”的假象——其实查的是同义词定义里的目标对象，而目标对象权限没开。
- 同义词本身不带权限，它只是别名；权限检查始终落在目标对象上
- 执行
SELECT * FROM v_report实际等价于SELECT * FROM sales.v_report，所以sales.v_report的SELECT权限必须存在 - 检查同义词指向：
SELECT base_object_name FROM sys.synonyms WHERE name = 'v_report' - 确保同义词所有者（
schema_owner）对目标视图有权限，或者直接给调用者授目标视图权限，别依赖同义词“继承”权限
权限迁移容易被忽略的三个细节
跨架构迁移视图时，最常卡在“看起来建好了、也能执行，就是查不出数据”。问题往往藏在权限链的某个断点上，而不是语法或数据本身。
-
EXECUTE AS上下文切换后权限重算：如果视图里用了EXECUTE AS OWNER或EXECUTE AS 'user'，那最终权限取决于那个执行上下文用户的权限，不是调用者——迁移后这个 owner 用户可能不存在或没对应权限 - 数据库级角色（如
db_owner）能绕过对象权限检查，但生产环境不该靠它兜底；临时加db_owner是排查手段，不是解决方案 - SQL Server 的权限是“授予即生效”，但不会自动传播：比如你给
sales架构授了SELECT，新创建的视图默认不自动获得该权限，除非显式GRANT或靠SCHEMA::级授权覆盖
