如何正确设置MySQL存储对象的SQL SECURITY-mysql教程-PHP中文网

sql security definer 和 invoker 的核心区别在于执行权限归属：definer 使用创建者权限，调用者无需底层权限；invoker 则严格校验调用者当前权限。

如何正确设置mysql存储对象的sql security

SQL SECURITY DEFINER 和 INVOKER 的区别在哪

关键在于「谁的权限被用来执行存储过程/函数」。DEFINER 用创建者权限执行，哪怕调用者只有 SELECT 权限；INVOKER 则严格按调用者当前权限检查——这是权限控制的核心分水岭。

常见错误现象：ERROR 1418（You do not have the SUPER privilege and binary logging is enabled），或函数创建成功但调用时报 Access denied，往往就是 SECURITY 模式与用户权限、binlog 配置不匹配导致的。

DEFINER 模式下，只要创建者有权限，调用者无需拥有底层表操作权，适合封装通用逻辑（如日志写入、统计计算）
INVOKER 模式下，调用者必须显式拥有被访问对象的权限，适合多租户或权限隔离场景
MySQL 8.0+ 默认为 SQL SECURITY DEFINER，但若未显式指定且创建者无 SUPER 权限 + binlog 开启，会直接拒绝创建

创建存储过程时必须显式声明 SQL SECURITY

不写 SQL SECURITY 并不等于“默认安全”——它可能触发隐式规则，尤其在开启 binlog 的生产环境里极易失败。

正确做法是始终显式写出，避免依赖版本差异：

CREATE PROCEDURE update_user_status(IN uid INT, IN new_status TINYINT)
    SQL SECURITY DEFINER
BEGIN
    UPDATE users SET status = new_status WHERE id = uid;
END

如果想让调用者权限生效，就写：

SQL SECURITY INVOKER

注意：SQL SECURITY 必须紧接在参数列表之后、BEGIN 之前，位置错位会导致语法错误。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

DEFINER 用户不存在或权限失效怎么办

当原创建者账号被删、密码重置、或权限被 revoke 后，DEFINER 模式下的存储对象会直接报错：ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。

修复方式不是重建，而是用 ALTER 重置 DEFINER：

先确认当前用户有 ALTER ROUTINE 权限
执行：ALTER PROCEDURE update_user_status SQL SECURITY DEFINER COMMENT '';（COMMENT 可省略，关键是重新声明 SECURITY）
更稳妥的是指定一个长期存在的高权限账户：ALTER PROCEDURE update_user_status DEFINER = 'admin'@'localhost' SQL SECURITY DEFINER;

不要用 root@% 作为 DEFINER，这会绕过 host 限制，扩大攻击面。

SQL SECURITY 对二进制日志和复制的影响

在主从复制场景中，DEFINER 模式可能导致从库执行失败：主库上由 admin@10.0.1.5 创建的过程，在从库上若无同名用户或权限不足，INSERT/UPDATE 就会中断 SQL 线程。

规避方法：

所有 DEFINER 用户必须在主从库上存在且权限一致（推荐统一用 admin@localhost）
对安全性要求不高、且调用者权限可控的场景，优先用 SQL SECURITY INVOKER，避免跨实例权限耦合
MySQL 8.0.30+ 支持 require_row_format 选项，可强制基于行的复制，缓解部分 DEFINER 权限不一致问题，但不能替代权限治理

真正容易被忽略的点：即使你没动过 DEFINER，升级 MySQL 或迁移 dump 时，mysqldump --routines 默认导出带原始 DEFINER 的语句，恢复到新环境前必须手工替换或加 --skip-definer 参数。