在MySQL中，存储过程、函数和触发器都属于数据库对象，其定义文本默认保存在系统库mysql的proc表以及information_schema的routines表中。任何拥有相应库权限或者能够执行SHOW CREATE PROCEDURE的账号，都可以读取这些源码。由于MySQL没有类似SQL Server的WITH ENCRYPTION这种原生加密选项，想要隐藏存储过程源代码，只能从权限与对象归属层面入手。DEFINER机制正是其中一个关键控制点。
一、理解DEFINER与权限检查机制
MySQL在创建存储过程时可以通过DEFINER子句指定该对象的“定义者”账号，例如'admin'@'localhost'。当其他用户调用这个存储过程时，如果对象的SQL SECURITY属性为DEFINER（默认就是DEFINER），那么过程体内的操作将以DEFINER账号的权限来执行，而不是调用者的权限。这意味着即便调用者本身没有某些表的写权限，只要DEFINER有，就能顺利完成操作。
从源码查看的角度看，DEFINER本身并不会自动隐藏代码，但它改变了权限边界。如果我们把存储过程定义为高权限账号所有，而日常业务账号仅被授予EXECUTE权限，没有SELECT权限去查information_schema.routines，也没有权限访问mysql.proc，那么这些业务账号虽然能调用过程，却无法看到过程体的具体内容。这就是通过DEFINER配合权限回收来限制查看的基本思路。
1.1 DEFINER与INVOKER的区别
除了DEFINER，存储过程还可以设置SQL SECURITY INVOKER，此时过程以调用者身份运行。显然，如果希望用统一的高权限账号隔离业务权限，应使用DEFINER。下面是一段创建存储过程的示例，显式声明DEFINER并仅授予执行为业务账号：
-- 使用高权限账号创建存储过程
CREATE DEFINER='db_admin'@'localhost' PROCEDURE proc_transfer(IN uid INT)
SQL SECURITY DEFINER
BEGIN
UPDATE accounts SET balance = balance - 100 WHERE user_id = uid;
INSERT INTO logs(action) VALUES('transfer');
END;
-- 业务账号仅获得执行权
GRANT EXECUTE ON PROCEDURE test_db.proc_transfer TO 'app_user'@'%';
上述代码中，app_user能调用proc_transfer，但因为没有被授权读取routine定义，在客户端执行SHOW CREATE PROCEDURE时会返回拒绝访问的错误。这样就初步实现了源码不可见。
1.2 系统表与查看入口
用户查看存储过程源码通常依赖三种方式：SHOW CREATE PROCEDURE、查询information_schema.ROUTINES表的ROUTINE_DEFINITION字段、以及直接读取mysql.proc表。要彻底限制，就必须让目标账号对后两者无权限，同时禁止其使用SHOW命令。MySQL的SHOW权限比较特殊，它依赖全局的SELECT或特定对象的权限，因此收回相关库的SELECT是有效手段。
| 查看方式 | 所需权限 | 限制方法 |
|---|---|---|
| SHOW CREATE PROCEDURE | 对该过程的EXECUTE或全局SELECT | 仅给EXECUTE，不给全局SELECT |
| information_schema.ROUTINES | 全局SELECT或库级SELECT | 收回业务账号的SELECT权限 |
| mysql.proc表查询 | mysql库SELECT | 禁止业务账号访问mysql库 |
二、通过账号与权限配置隐藏源码
实际落地时，建议采用“管理账号+业务账号”分离模式。管理账号拥有所有权限，负责创建和维护存储过程，并统一使用自身作为DEFINER；业务账号只拿最小权限，仅能连接、执行指定过程、读写指定表，不能看结构定义。
下面给出一套可操作的权限配置步骤。先在管理端创建过程，然后明确回收业务账号可能对系统表产生读取的一切权限。注意，MySQL 8.0之后mysql.proc已被废弃，源码主要存在information_schema和performance_schema中，但权限控制逻辑一致。
2.1 创建并授权业务账号
假设我们已经以root登录，先建一个只有test_db使用权的业务账号，并只给表级读写与过程执行权：
-- 创建业务账号 CREATE USER 'app_user'@'%' IDENTIFIED BY 'StrongPass_123'; -- 授予业务库表读写 GRANT SELECT, INSERT, UPDATE, DELETE ON test_db.* TO 'app_user'@'%'; -- 仅授予执行存储过程，不授予SHOW权限相关能力 GRANT EXECUTE ON test_db.* TO 'app_user'@'%'; -- 确保没有全局或mysql库权限 REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'app_user'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON test_db.* TO 'app_user'@'%';
这样app_user在客户端尝试运行SHOW CREATE PROCEDURE test_db.proc_transfer时，如果MySQL判定其无权限，会报ERROR 1142 (42000): SELECT command denied，因为SHOW CREATE在权限校验上需要对应对象的元数据读取权。不同版本提示可能略有差异，但核心是看不到源码。
2.2 使用视图进一步隔离
有些ORM或中间件会主动查询information_schema，如果业务账号连库级SELECT都没有，可能连普通表结构也查不到，影响自动映射。此时可以为其创建特定视图并授予视图的SELECT，而存储过程依旧只给EXECUTE。由于视图定义和过程定义分开管理，源码隐藏不受影响。
-- 为业务账号开放某视图而非基表结构 CREATE VIEW test_db.v_user_balance AS SELECT user_id, balance FROM test_db.accounts; GRANT SELECT ON test_db.v_user_balance TO 'app_user'@'%';
此方式兼顾了开发便利与安全。业务端只能通过视图拿数据，通过过程写逻辑，永远触达不到存储过程体的文本。
三、常见误区与补充措施
不少人以为把存储过程写成临时表或拼接SQL就能防看，其实只要权限放开，源码依然透明。真正可靠的做法还是权限模型收紧。另外，拥有SUPER或READ_ONLY_ADMIN之类高级权限的账号天然能看所有定义，因此这类账号绝不能分发给应用层。
如果数据库允许外部直连，还应结合网络白名单、SSL连接与审计日志。源码隐藏只是降低泄露风险，不能替代整体安全策略。对于极度敏感的算法，更合理的是放到应用层或用外部程序封装，数据库端只保留最简单的数据操作。
3.1 验证隐藏效果
配置完成后，用业务账号登录并执行如下检查，确认无法获取定义：
-- 应能执行，但看不到体 CALL test_db.proc_transfer(10); -- 以下应报错或无记录 SHOW CREATE PROCEDURE test_db.proc_transfer; SELECT ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE ROUTINE_NAME='proc_transfer';
若两条查询均被拒绝或返回空，说明DEFINER配合权限限制已生效。日后新增存储过程时，务必统一用管理账号定义并重复上述授权流程，避免人为授予过多权限导致源码再次暴露。
3.2 版本差异注意
MySQL 5.7与8.0在系统表结构上有所不同，但DEFINER与EXECUTE权限的行为保持一致。升级数据库时，需重新核对业务账号权限，因为某些导入导出操作可能悄悄带上VIEW_DEFINITION或ROUTINE权限。建议用SHOW GRANTS FOR 'app_user'@'%'定期审查，确保没有异常权限累加。
总体来看，虽然MySQL不提供存储过程加密，但借助DEFINER指定归属、最小化业务账号权限、隔离系统表访问，足以在日常运维中有效隐藏源代码，降低核心逻辑外流风险。