MySQL触发器无法获取真实登录用户，必须用CURRENT_USER()比对账号并结合BEFORE UPDATE拦截；USER()返回连接声明身份，CURRENT_USER()返回认证账号，后者更可靠，但均需应用层配合传入才可精准鉴权。
BEFORE UPDATE触发器里怎么判断修改者身份
MySQL触发器本身不暴露当前连接的用户名，USER() 或 CURRENT_USER() 在触发器中可用，但要注意区别：USER() 返回客户端声明的身份（可能含 host），CURRENT_USER() 返回认证通过的账号（更可靠）。若需按用户限制列修改，必须在触发器里显式比对，例如：IF CURRENT_USER() = 'reporter'@'10.20.%' AND NEW.salary != OLD.salary THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'reporter cannot modify salary'; END IF;
禁止修改敏感列的触发器写法要点
核心是利用 BEFORE UPDATE + OLD/NEW 虚拟表做值比对，命中即中断。常见错误是只检查 NEW.col IS NOT NULL ——这无法识别“设为 NULL”或“从 NULL 改为非 NULL”的修改。
- 必须用
NEW.col != OLD.col（注意 NULL 安全比较，推荐改用NOT (NEW.col OLD.col)） - 多个列要分别判断，不能合并到一个 IF 里，否则任一列未改就跳过拦截
- 避免在触发器里调用函数查权限表——开销大、易锁表、且结果可能被缓存
- 字段名必须用反引号包裹，尤其含数字或特殊字符时，如
`created_at`
为什么不能靠 GRANT 控制单列写权限
MySQL 原生不支持列级 UPDATE 权限。执行 GRANT UPDATE(col_a) ON db.t TO 'u'@'h' 是语法错误；GRANT UPDATE ON db.t 是整表授权，无法拆分。唯一可行路径只有两种：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 建视图（如
CREATE VIEW t_ro AS SELECT id, name FROM t），再授UPDATE给视图，并加WITH CHECK OPTION，但应用必须走视图，直连基表就失效 - 用触发器硬拦截，这是最直接、最可控的方式，也是生产环境事实标准
跨用户场景下容易忽略的兼容性细节
不同 MySQL 版本对触发器内函数的支持有差异，尤其涉及时间、用户、字符集时：
-
CURRENT_USER()在 MySQL 5.7+ 稳定可用，但 5.6 及更早版本中某些嵌套场景可能返回空值 - 若用户 host 是通配符（如
'user'@'%'），而实际连接来自192.168.1.100，CURRENT_USER()仍返回'user'@'%'，可直接比对 - 触发器中不要用
SLEEP()或复杂子查询，会显著拖慢写入，且在高并发下易引发锁等待 - 测试时务必用真实账号连接验证，别只在 root 下跑 —— 权限上下文和
CURRENT_USER()输出可能完全不同
触发器逻辑看似简单，但一旦部署到生产，所有写请求都经它过滤，任何隐式类型转换、NULL 处理偏差或 host 匹配疏漏，都会导致误拦或漏拦。最稳妥的做法是：先在测试库用目标账号完整走一遍 UPDATE 流程，再查 SHOW ENGINE INNODB STATUS 确认无锁等待，最后上线。
