trigger权限需显式授予且不包含在all privileges中，必须用grant trigger on mydb.*授权；触发器内sql还需对应对象的insert/select/execute等权限；修改触发器需同时拥有trigger和drop权限；推荐使用专用库+角色隔离最小化权限范围。
TRIGGER权限必须显式授予，不能靠ALL PRIVILEGES自动获得
MySQL 5.7+ 中 TRIGGER 是独立权限类型，即使你执行了 GRANT ALL PRIVILEGES ON mydb.* TO 'dev'@'%'，也不会包含 TRIGGER。创建触发器时会直接报错：ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or TRIGGER privilege(s) for this operation。
必须由具备 GRANT OPTION 的账号（如 root 或专用授权角色）执行：
GRANT TRIGGER ON `mydb`.* TO 'dev'@'%';
-
ON mydb.*是合法范围；ON mydb.orders会报ERROR 1064；ON *.*虽语法允许，但生产环境应禁止 - 权限作用域是数据库级，不是表级——哪怕你只想让开发管一张表的触发器，也得给整个库的
TRIGGER权限 - 授完权后无需
FLUSH PRIVILEGES（GRANT语句已自动刷新），但客户端需重连才能生效
触发器体里每条SQL都对应额外权限需求
光有 TRIGGER 权限远远不够。触发器运行时以调用者身份检查权限，它内部写的每条语句，都要求用户对涉及对象有对应操作权限。
例如这个 BEFORE INSERT 触发器：
CREATE TRIGGER set_order_status BEFORE INSERT ON orders FOR EACH ROW SET NEW.status = 'pending';
- 只改
NEW字段 → 只需TRIGGER权限即可
但若改成：
CREATE TRIGGER log_order BEFORE INSERT ON orders
FOR EACH ROW INSERT INTO audit_log (msg) VALUES (CONCAT('new order: ', NEW.id));
- 必须额外授予：
GRANT INSERT ON mydb.audit_log TO 'dev'@'%' - 如果触发器里还
SELECT COUNT(*) FROM users WHERE id = NEW.user_id→ 还要补SELECT权限 - 调用了函数
gen_uuid()？得加：GRANT EXECUTE ON FUNCTION mydb.gen_uuid TO 'dev'@'%' - 写入另一库的表（如
sys.log_table）？权限必须单独授到那个库：GRANT INSERT ON sys.log_table TO 'dev'@'%'
修改触发器本质是 DROP + CREATE，需要双重权限
MySQL 不支持 ALTER TRIGGER。所谓“修改”，实际分两步：先 DROP TRIGGER，再 CREATE TRIGGER。这就要求用户同时拥有：
-
TRIGGER权限（用于重建） -
DROP权限（用于删除原触发器）——注意不是对表，而是对数据库：GRANT DROP ON `mydb`.* TO 'dev'@'%'
漏掉 DROP 权限，执行 DROP TRIGGER trig_name 时会直接报错：ERROR 1142 (42000): DROP command denied to user。
更隐蔽的坑是：如果触发器定义里指定了 DEFINER = 'admin'@'localhost'，而该用户账号已被删或失效，触发器虽能创建成功，但运行时报错（如 ERROR 1449: The user specified as a definer does not exist）。
生产环境推荐用角色隔离 + 专用触发器库
直接在业务库上开放 TRIGGER 权限风险高，因为一旦有了该权限，开发就能为库内任意表建触发器（包括系统表或敏感表）。更安全的做法是：
- 新建一个专用库，比如
triggers_db，只放触发器、日志表、辅助函数等 - 把业务表上的触发逻辑全部迁入该库，并用跨库语句（如
INSERT INTO triggers_db.audit_log）操作 - 只对这个专用库授
TRIGGER、INSERT、EXECUTE等权限：GRANT TRIGGER, INSERT, EXECUTE ON `triggers_db`.* TO 'dev'@'%' - 配合 MySQL 8.0+ 角色机制：
CREATE ROLE trigger_dev; GRANT TRIGGER ON triggers_db.* TO trigger_dev; GRANT trigger_dev TO 'dev'@'%';
这样既满足功能需求，又把权限影响面缩到最小——真正容易被忽略的，不是“怎么授”，而是“在哪授”和“和谁一起授”。
