sql server中with encryption仅模糊视图定义，不改变权限机制；用户仍需被显式授予对视图及底层对象的select权限，否则查询失败。
SQL Server 2019 中的视图本身不支持“加密”（ENCRYPTION 选项仅适用于存储过程、函数、触发器和视图的 定义文本，而非数据内容），所以所谓“加密视图”实际是指用 WITH ENCRYPTION 创建的**加密定义视图**——它的查询逻辑被模糊化，但权限控制机制与普通视图完全一致，不因加密而改变。
WITH ENCRYPTION 视图能否绕过权限检查？
不能。视图是否加了 WITH ENCRYPTION 对权限验证毫无影响。SQL Server 在执行 SELECT 时仍会严格校验调用者对视图本身的 SELECT 权限，以及视图底层所引用对象（表、函数等）的隐式访问权限。即使视图定义被加密，只要用户没有 SELECT 权限，照样报错：The SELECT permission was denied on the object 'xxx', database 'yyy', schema 'zzz'.
- 加密只防止他人用
sp_helptext或系统视图（如sys.sql_modules）查看视图定义 - 它不提供额外安全隔离，也不替代显式授权
- 如果视图引用了用户无权访问的基表，即使有视图
SELECT权限，查询仍会失败
给 WITH ENCRYPTION 视图授予权限的正确写法
语法和普通视图完全一样，唯一区别是创建时加了 WITH ENCRYPTION。授权必须显式执行，不能依赖基表权限自动继承：
CREATE VIEW dbo.vw_SensitiveData WITH ENCRYPTION AS SELECT id, name, salary FROM dbo.Employees WHERE dept = 'HR'; GO <p>GRANT SELECT ON dbo.vw_SensitiveData TO [hr_analyst];</p>
-
GRANT必须针对视图名（如dbo.vw_SensitiveData），不是基表 - 若希望用户也能看到视图元数据（比如出现在 SSMS 对象资源管理器中），还需额外授予
VIEW DEFINITION权限（否则视图在 UI 中不可见） - 角色授权更推荐：先
CREATE ROLE hr_reader，再GRANT SELECT ON ... TO hr_reader，最后ALTER ROLE hr_reader ADD MEMBER [hr_analyst]
常见权限失败原因和排查点
用户能连上数据库、能看到视图名，但执行 SELECT * FROM vw_xxx 报错，大概率卡在这几个环节：
- 没执行
GRANT SELECT ON [view_name] TO [user]—— 最常见疏漏 - 视图里用了函数或跨库表（如
OtherDB.dbo.Table），但用户对那些对象无权限 - 用户属于
public角色，但数据库级VIEW ANY DATABASE被禁用，导致无法展开数据库节点（SSMS 中看不见视图，误以为没授权） - 用
DENY SELECT显式拒绝过该用户或其所属角色——DENY优先级高于GRANT，会直接覆盖 - 视图定义中含
EXECUTE AS子句，且指定的执行上下文（如OWNER）无权访问基表
真正关键的不是“怎么加密”，而是“加完之后是否忘了授访问权”。WITH ENCRYPTION 容易让人误以为它自带访问控制，其实它只是藏起了 SQL 文本——权限还得一行行手动配，一个都不能少。
