WITH ENCRYPTION 仅阻止常规方式查看视图定义，但无法防止查询使用、权限绕过或元数据泄露，且ALTER VIEW必须显式重写才能维持加密，否则失效。

WITH ENCRYPTION 能阻止常规方式查看视图定义，但不是万能锁，用错等于没加。

加密后哪些地方真的看不到源码

加了 WITH ENCRYPTION 的视图，以下操作会失效或报错：

• sp_helptext 'vw_name' 返回空结果或报错 Cannot view the text for this object, because it is encrypted.
• SSMS 右键 → “脚本为 → CREATE 到” 生成空白或失败
• 查询 sys.sql_modules 时，definition 字段为 NULL
• 即使有 VIEW DEFINITION 权限，也拿不到明文

这不是权限问题，是 SQL Server 在创建/修改时就丢弃了原始文本——没有密钥可解，也没有缓存可捞。

ALTER VIEW 必须重写整条语句才能维持加密

常见错误是只改逻辑、漏掉 WITH ENCRYPTION。SQL Server 不把它当开关，而是当作创建选项的一部分。

• 已有视图未加密，执行 ALTER VIEW vw_sales_summary AS SELECT ... → 加密失效
• 必须显式写成 ALTER VIEW vw_sales_summary WITH ENCRYPTION AS SELECT ...
• 没有 ADD ENCRYPTION 或 SET ENCRYPTION = ON 这种语法
• 如果记不清原逻辑，又没提前备份，只能靠执行计划、统计 IO 或依赖关系反推，非常被动

加密后无法图形化修改，所有变更都得 DROP + RECREATE

SSMS 点“修改”会直接报错：Cannot modify encrypted objects.

• 不能右键 → “修改”，也不能双击打开设计器
• 后续任何调整（哪怕只加个字段别名）都只能：先 DROP VIEW，再 CREATE VIEW ... WITH ENCRYPTION AS ...
• 这意味着你必须人工维护一份完整、准确、带注释的源码副本，否则上线即失联
• CI/CD 流程中若没把加密视图脚本纳入版本管理，一次误操作就可能永久丢失逻辑

它不防查询，也不替代权限控制

WITH ENCRYPTION 只管“看”，不管“用”。只要用户有 SELECT 权限，就能正常查出结果，甚至通过结果反推逻辑。

• 仍需显式 REVOKE VIEW DEFINITION ON OBJECT::vw_name TO [user]，否则高权限账号可能绕过
• 视图里用 CASE WHEN 脱敏？攻击者查 INFORMATION_SCHEMA.VIEWS 就能看到字段名和表达式结构
• 生产环境应限制对 INFORMATION_SCHEMA 和 sys.views 的 SELECT 权限，否则加密形同虚设

真正难的是权衡：加了加密，开发运维成本陡增；不加，源码裸奔。最常被忽略的一点是——它和权限管控必须一起上，单靠 WITH ENCRYPTION 没法挡住有心人。