sql server的with encryption仅防普通用户直查，dba、备份提取、内存dump、执行计划缓存等仍可还原明文；mysql不支持该语法，始终明文可见；pg需用security definer+视图封装逻辑，三者均非真正源码加密。

SQL Server 的 WITH ENCRYPTION 不是加密，只是防普通用户直查；MySQL 根本不支持该语法；PostgreSQL 需靠 SECURITY DEFINER + 视图封装——三者都做不到真正“源码加密”，只能控制谁能看到、在哪看到。

SQL Server 用 WITH ENCRYPTION 后还能被看到吗

能。它只让 sp_helptext 和 sys.sql_modules.definition 返回空或乱码，但以下情况仍可还原明文：

• DBA 或拥有 VIEW SERVER STATE 权限的人，可通过查询执行计划缓存（sys.dm_exec_query_plan）提取原始文本
• 启用专用管理员连接（DAC）后，直接读取内存页或系统表原始数据块
• 从数据库备份文件中提取 sys.sysobjvalues 表内容并解密（SQL Server 内部使用动态密钥，首次执行时解密到内存）
• 第三方工具如 SQL Prompt（7.0+）在预览对象时会自动显示明文，无需额外操作

另外，加密后无法用 ALTER PROCEDURE 修改，必须先 DROP 再 CREATE，线上误删风险陡增。

MySQL 存储过程根本不能加 WITH ENCRYPTION

该关键字在 MySQL 中是无效语法：不报错、不生效、也不提示，只默默忽略。所有存储过程源码始终暴露在以下位置：

• SHOW CREATE PROCEDURE p_name
• SELECT ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE ROUTINE_NAME = 'p_name'
• SELECT body FROM mysql.proc WHERE name = 'p_name'（只要账号有 SELECT 权限）

常见错误是把 SQL Server 写法直接复制进 MySQL，以为加了就安全了。真正可行的只有权限隔离：

商量SenseChat

商量SenseChat是一款AI工具，商汤科技推出的免费AI聊天助手。

下载

• REVOKE SHOW ROUTINE ON *.* FROM 'app_user'@'%'
• REVOKE SELECT ON information_schema.ROUTINES FROM 'app_user'@'%'
• REVOKE SELECT ON mysql.proc FROM 'app_user'@'%'
• 仅授予 EXECUTE 权限：GRANT EXECUTE ON PROCEDURE db.p_name TO 'app_user'@'%'

PostgreSQL 怎么隐藏 pg_proc.prosrc

PG 没有原生加密选项，但可通过组合机制限制调用者视角：

• 创建 SECURITY DEFINER 函数，其执行权限以函数所有者身份进行，调用者无法查 pg_proc.prosrc
• 再用视图包装该函数结果，对外只暴露字段，不暴露逻辑来源
• 禁用 pg_read_all_data 等高权限角色给普通用户

注意：超级用户仍可直接查 pg_proc，且若函数内含 RAISE NOTICE 或日志输出，可能泄露线索。混淆变量名、拼接字符串等手段对 PG 无实质防护作用，只是徒增维护成本。

别碰“运行时解密执行”这种想法

网上流传的用 AES_ENCRYPT() 或 Base64 加密整个过程体、再用 PREPARE/EXECUTE 动态还原执行——这在任何主流 SQL 引擎中都不可行：

• SQL Server 不支持将加密字符串解密后作为 T-SQL 执行（sp_executesql 只接受明文字符串）
• MySQL 的 PREPARE 要求输入为字面量或变量，但变量内容无法在运行时“解密并重编译成新存储过程”
• PostgreSQL 的 EXECUTE 也不能执行加密后的函数体字符串

所谓“加固”，本质是权限边界和逻辑分层问题：敏感计算前移到应用层（Python/Java），数据库只做原子读写；硬编码密钥比“加密过程”更危险，且更容易被忽略。