在项目交付或数据库托管场景中，客户或第三方运维人员往往拥有查询系统表的权限，普通视图的定义会被明文存储在sys.sql_modules系统视图中，任何人执行一句SELECT就能把你的业务逻辑看得一清二楚。SQL Server针对这个需求提供了WITH ENCRYPTION选项，它可以把视图、存储过程、触发器、函数等对象的定义加密存储，从根本上避免源码被随意查看。本文以视图为例，讲解这一功能的完整用法和注意事项。
一、视图源码默认是公开的
在讲解加密之前，先看看不加密的视图是什么状态。假设我们创建一个计算销售提成的视图：
CREATE VIEW dbo.vw_SalesCommission
AS
SELECT OrderID, CustomerName, Amount,
Amount * 0.15 AS Commission
FROM dbo.SalesOrders
WHERE OrderStatus = 'Completed';
创建完成后，任何拥有足够权限的用户都可以通过以下几种方式查看它的定义：
-- 方式一：系统存储过程
EXEC sp_helptext 'dbo.vw_SalesCommission';
-- 方式二：直接查询系统视图
SELECT definition
FROM sys.sql_modules
WHERE object_id = OBJECT_ID('dbo.vw_SalesCommission');
这两种方式都会返回完整的CREATE VIEW语句，包括提成的计算比例0.15这种敏感的商务规则。如果是普通的企业内部系统，这可能无所谓；但如果你的产品是按license销售、数据库要部署到客户机房，源码裸奔就意味着核心逻辑拱手送人。
二、使用WITH ENCRYPTION加密视图
WITH ENCRYPTION是CREATE VIEW和ALTER VIEW语句的可选子句，写在AS关键字之前即可。创建加密视图的完整语法如下：
CREATE VIEW dbo.vw_SalesCommission
WITH ENCRYPTION
AS
SELECT OrderID, CustomerName, Amount,
Amount * 0.15 AS Commission
FROM dbo.SalesOrders
WHERE OrderStatus = 'Completed';
如果视图已经存在，想对现有视图追加加密，需要使用ALTER VIEW重写完整定义，不能只写一句ALTER VIEW ... WITH ENCRYPTION就完事，因为ALTER VIEW要求把整个视图定义重新声明一遍：
ALTER VIEW dbo.vw_SalesCommission
WITH ENCRYPTION
AS
SELECT OrderID, CustomerName, Amount,
Amount * 0.15 AS Commission
FROM dbo.SalesOrders
WHERE OrderStatus = 'Completed';
加密生效后，再执行sp_helptext会直接返回“对象已加密”的提示，查询sys.sql_modules时definition列返回NULL，SSMS中右键“编写视图脚本为”也会失败。加密后的视图在功能上完全不受影响，正常查询、联接、授权都没有问题，用户感知不到任何差别。
三、加密后的管理与常见坑
WITH ENCRYPTION好用，但有几个坑必须提前知道，否则可能把自己也锁在门外。
第一，务必保留原始脚本。加密是不可逆的，SQL Server没有任何官方命令可以解密视图定义。一旦丢失了源码脚本，你将无法修改这个视图的逻辑，只能删除重建。所以建议把所有加密对象的DDL脚本纳入版本管理，每次修改前先从代码仓库取出最新版本。
第二，修改加密视图必须整段重写。如上文所示，ALTER VIEW时同样要带上WITH ENCRYPTION子句。如果ALTER时忘记写WITH ENCRYPTION，视图会被重新解密存储，保护立即失效，这是一个非常常见的疏漏。
第三，权限控制仍然要做。加密只是隐藏定义，不等于访问控制。用户依然可以查询视图返回的数据，也可以通过查询系统目录看到视图依赖的表和列名。敏感数据仍需配合GRANT/DENY权限、行列级安全策略一起使用。
验证对象是否已加密，可以查询is_encrypted列：
SELECT name, is_encrypted
FROM sys.views
WHERE schema_id = SCHEMA_ID('dbo');
is_encrypted为1表示定义已加密，建议在数据库发布流程中加入这个检查，防止交付漏网之鱼。
四、方案局限与补充建议
需要客观说明的是，WITH ENCRYPTION的加密强度有限。定义在服务器内部是以可还原的形式存储的，市面上存在一些通过DAC（专用管理员连接）读取解密内容的第三方工具。因此它的定位是“防君子不防小人”，能够挡住普通用户和大多数运维人员，但不能应对有经验的逆向人员。
如果对安全性要求更高，可以考虑以下补充措施的组合：一是把核心计算逻辑移到应用程序层或中间服务，数据库只暴露纯数据接口；二是使用SQL Server的Always Encrypted对敏感列本身加密，让数据库端根本接触不到明文；三是对交付环境的登录账号严格分权，收回VIEW DEFINITION权限，让用户连系统目录都难以窥探。
总的来说，WITH ENCRYPTION是成本最低、见效最快的视图源码保护手段，一条子句就能挡住绝大多数窥探。配合规范的脚本管理和权限体系，足以应对绝大多数交付场景下的知识产权保护需求。
SQL Server视图加密WITH ENCRYPTION视图源码保护修改时间：2026-09-10 02:30:26