MySQL触发器无法获取真实业务用户ID，USER()和CURRENT_USER()仅返回数据库连接账户；必须由应用层显式传参（如存储过程入参或会话变量）或在应用/代理层完成权限校验。
MySQL触发器里拿不到USER()以外的登录上下文
MySQL触发器本身无法访问应用层传入的「业务用户ID」或「角色信息」，USER() 和 CURRENT_USER() 返回的是数据库连接账户（比如 'app@10.0.1.5'），不是你系统里的 user_id=123。想在触发器里做「张三不能删李四的订单」这类校验，纯靠触发器做不到——它没入口接收这个参数。
替代方案：用存储过程封装写操作 + 应用层显式传参
把 INSERT/UPDATE/DELETE 逻辑移到存储过程中，让应用在调用时把当前业务用户信息作为参数传进来。触发器不负责权限判断，只做数据一致性维护（比如自动生成日志、更新统计字段）。
CREATE PROCEDURE update_order_status(IN p_user_id INT, IN p_order_id INT, IN p_new_status VARCHAR(20))- 过程内先查
SELECT user_role FROM users WHERE id = p_user_id，再 JOIN 订单表验证归属关系 - 校验失败直接
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Permission denied' - 通过后再执行
UPDATE orders ...和触发器自动触发的审计日志逻辑
如果硬要用触发器，只能依赖连接账户映射（极有限场景）
仅当数据库账号与业务用户严格一一对应（例如每个业务用户独占一个DB账号），才可能用 CURRENT_USER() 做粗粒度拦截。但实际中几乎不可行：
- 连接池会让多个业务用户共享同一个DB账号（如
'webapp@%'） - 账号名格式不统一：
'u123@192.168.%'解析出123需要正则，MySQL 5.7 不支持REGEXP_SUBSTR，8.0 才有，且性能差 - 无法区分同账号下不同会话的业务上下文（比如同一账号同时操作多个租户数据）
真正该拦截的位置是应用层或数据库代理层
权限校验必须发生在「知道完整业务上下文」的地方。常见落地方式：
- ORM 层（如 Django 的
save()方法重写、MyBatis 的@UpdateProvider）注入用户ID做前置检查 - API 网关或中间件统一解析 JWT，把
user_id、tenant_id注入 SQL 查询的 WHERE 条件（如WHERE order_id = ? AND user_id = ?） - 使用 ProxySQL 或 MaxScale 做语句重写，在到达 MySQL 前补全租户过滤条件
试图在触发器里做权限拦截，本质是把本该由业务逻辑承担的责任错压给存储引擎，最终要么漏判，要么误杀，还难以调试。
