MySQL触发器无法获取业务角色信息，因CURRENT_USER()返回连接身份而非业务角色，CURRENT_ROLE()恒为空；必须由应用层通过SET @current_role显式传入角色标识供触发器校验。
不能直接在MySQL触发器里做基于角色的行级权限控制——触发器无法可靠获取当前业务用户所属角色，更无法动态查角色-权限映射表。真要实现行级隔离，必须把角色信息由应用层显式传入，再在触发器中做静态比对。
为什么触发器拿不到有效的角色信息
MySQL 触发器执行时，CURRENT_USER() 和 USER() 返回的是数据库连接身份（如 'app_rw'@'10.20.30.5'），不是业务系统里的角色（如 'editor' 或 'region_manager'）。它和你 GRANT 'editor' TO 'app_user'@'%' 里的角色完全无关，也不会受 SET DEFAULT ROLE 影响。触发器里调用 CURRENT_ROLE() 永远返回 NULL 或空字符串，因为角色是会话级状态，而触发器不继承会话激活的角色上下文。
应用层必须显式传入角色标识
唯一可行路径是让应用在执行 DML 前，先用 SET @current_role = 'editor' 注入当前业务角色，然后触发器读取该用户变量。这个过程必须严格串行、不可省略：
- 应用连接后，立即执行
SET @current_role = 'editor'（不能依赖连接池自动初始化，需确认连接池支持connection-init-sql） - 触发器中用
@current_role做判断，例如：IF @current_role NOT IN ('admin', 'region_manager') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '无权操作'; END IF; - 禁止在触发器里执行
SELECT role FROM user_roles WHERE user_id = ...—— 这会引入锁、I/O 和权限表查询依赖，高并发下极易阻塞
INSERT/UPDATE 触发器中校验行归属字段时，别混淆“角色”和“归属ID”
常见错误是误以为“用户属于 editor 角色”就等于“能操作所有 editor 创建的数据”。实际业务规则往往是：某条记录只能由创建者（created_by 字段值）或同部门管理员修改。这时触发器应检查的是字段值匹配，而不是角色名：
-
INSERT：强制NEW.created_by = @current_user_id（注意：这里传的是用户ID，不是角色） -
UPDATE：同时验证OLD.created_by = @current_user_id（原属自己）且NEW.status等非归属字段未被越权篡改 - 若真要用角色控制访问范围（如“region_manager 可看本区域所有订单”），必须把区域 ID 存进记录（如
region_code字段），再让应用传入@current_region = 'shanghai'，触发器比对NEW.region_code = @current_region
真正该用角色的地方是 GRANT 层，不是触发器
MySQL 8.0+ 的 ROLE 功能只适合控制“能不能连表、能不能 SELECT”，不适合控制“能不能查哪几行”。你应该：
- 用
CREATE ROLE 'order_viewer'+GRANT SELECT ON orders TO 'order_viewer'控制表级可读 - 用
SET DEFAULT ROLE 'order_viewer' TO 'webapp'@'%'确保连接一上来就有基础权限 - 把行级过滤逻辑全放在应用层 SQL 的
WHERE条件里（如WHERE region_code = ? AND status != 'deleted'），而不是塞进触发器 - 触发器只保留最硬性的兜底检查：比如禁止
UPDATE salary_records.salary除非@current_role = 'hr'，这种字段级防护才符合触发器定位
复杂行级策略一旦进触发器，就等于把应用逻辑钉死在数据库里——改个权限规则得改 SQL、压测、上线，还绕不开 DBA。真正的灵活性来自应用层组装条件，而不是靠触发器硬编码角色名。
