ERROR 1449表示DEFINER用户不存在，需通过DROP+CREATE重建对象或ALTER PROCEDURE（MySQL 8.0.16+且有SET_USER_ID权限）修复；默认SQL SECURITY为DEFINER，启用INVOKER必须显式声明。
DEFINER 账户不存在时会直接报错 ERROR 1449
创建存储过程或视图时如果指定了 DEFINER='xxx'@'%' ，但该账户在 mysql.user 表中已被删除，调用时就会触发 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。这不是权限不足，而是身份上下文根本无法建立。
- 不能靠
GRANT恢复——账户必须真实存在且能通过认证 - 修复方式只有两种：
DROP + CREATE重建对象，或（MySQL 8.0.16+）用ALTER PROCEDURE proc_name DEFINER = 'new_user'@'%'修改，但需拥有SET_USER_ID权限 - 检查当前定义：运行
SHOW CREATE PROCEDURE proc_name，注意输出里DEFINER字段的完整值，包括 host 部分（'admin'@'localhost'和'admin'@'%'是两个不同主体）
INVOKER 不是默认行为，必须显式声明
很多人以为“不写 DEFINER 就是 INVOKER”，其实不是。MySQL 默认行为是 SQL SECURITY DEFINER，即使你省略 SQL SECURITY 子句，也等价于写了 SQL SECURITY DEFINER。
- 要真正启用 INVOKER 语义，必须显式写出
SQL SECURITY INVOKER - 推荐写法是：
CREATE DEFINER = CURRENT_USER SQL SECURITY INVOKER PROCEDURE ...—— 这样既避免依赖隐式默认值，又明确表达“以调用者权限执行” -
CURRENT_USER()返回的是连接认证用户（如'app_user'@'10.0.2.5'），而USER()返回的是带 host 的完整连接字符串，在代理用户场景下二者可能不同，影响权限判断
动态 SQL（PREPARE/EXECUTE）绕过 DEFINER 权限
哪怕整个存储过程设为 SQL SECURITY DEFINER，只要内部用了 PREPARE + EXECUTE 执行拼接的 SQL，这部分语句仍按 INVOKER 规则校验权限——这是最常被忽略的安全盲区。
- 例如：过程以
root身份定义，但里面SET @sql = CONCAT('SELECT * FROM ', table_name); PREPARE stmt FROM @sql; EXECUTE stmt;—— 实际执行时，MySQL 会检查调用者是否有对table_name的 SELECT 权限，而非root的权限 - 这种设计本意是防止恶意构造 SQL 提权，但也会导致预期外的权限拒绝，比如调用者有视图权限但无底层表权限时，
EXECUTE直接失败 - 规避方法：要么把动态部分涉及的表权限也授给调用者；要么改用静态 SQL + 参数化查询（如
WHERE id = ?）
视图权限和底层表权限是两套独立体系
视图本身是一级对象，它的访问权限（SELECT ON view_name）和它所依赖的表权限互不继承。这点在 SQL SECURITY INVOKER 下尤为关键。
- DEFINER 模式下：只需给用户授予视图的
SELECT权限，就能查视图，哪怕他完全没碰过底层表 - INVOKER 模式下：用户必须同时拥有视图的
SELECT权限 和 视图中所有引用表的对应权限（如SELECT ON t1,SELECT ON t2） - 常见误判：用户能查原表却查不了同名视图，大概率是因为视图用了
SQL SECURITY INVOKER，但没给他授底层表权限
实际部署时，别只盯着 SQL SECURITY 选哪个，先想清楚：这个过程/视图到底该由谁来承担数据访问责任？是封装逻辑的“可信中间层”，还是暴露给调用者的“透明代理”。前者倾向 DEFINER（但务必用专用低权账号），后者必须 INVOKER（并同步管理好调用者权限）。
