MySQL触发器中禁止使用COMMIT/ROLLBACK，因运行在主事务上下文中；日志表须用InnoDB引擎；NEW.id仅在主键为AUTO_INCREMENT时有效；避免复杂计算、跨库未指定库名、权限不足等问题。
触发器里不能用事务控制语句
MySQL 的 AFTER INSERT 触发器里写 COMMIT 或 ROLLBACK 会直接报错：ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这是因为触发器运行在主 SQL 事务上下文中，它自己不能开启或结束事务。
实操建议：
- 日志表必须用
InnoDB引擎（支持事务），否则主事务回滚时日志可能已落盘，造成不一致 - 避免在触发器里调用含隐式提交的语句，比如
ALTER TABLE、CREATE TABLE、TRUNCATE TABLE - 如果真要记录失败场景，得靠应用层捕获主 SQL 错误后补日志，触发器只管“成功插入后”的确定性动作
NEW 关键字取不到自增 ID 的坑
在 AFTER INSERT 触发器中，NEW.id 是可用的——但前提是该字段是主键且定义为 AUTO_INCREMENT。如果表结构里主键是 UUID 或由应用生成，NEW.id 就只是你 INSERT 时显式传入的值，不会自动补全。
常见错误现象：日志里 record_id 字段为空或为 0，查了半天发现原表主键根本没设 AUTO_INCREMENT。
实操建议：
- 建表时确认主键带
AUTO_INCREMENT，例如：id INT PRIMARY KEY AUTO_INCREMENT - 不要依赖
LAST_INSERT_ID()在触发器里取 ID——它返回的是当前会话最后一次INSERT的自增值，但在触发器里不可靠，尤其并发时 - 日志表字段类型要和原表严格一致，比如原表
id是BIGINT UNSIGNED，日志表对应字段也得是，否则可能截断或报错
触发器性能敏感点：别在日志里做复杂计算
每次 INSERT 都会同步执行触发器逻辑，哪怕只是多加一个 MD5(NEW.content) 或 CONCAT(NEW.name, '@', NEW.domain)，在高并发写入场景下都可能成为瓶颈。
使用场景提醒：日志表本身如果也加了全文索引、唯一约束或外键，会进一步拖慢主表写入速度。
实操建议：
- 日志字段尽量只存原始值，格式化、脱敏、拼接等操作留给查询时做
- 避免在触发器里调用存储函数（尤其是含 SQL 查询的），那等于在每次插入时嵌套一次查询
- 如果日志需写入远程系统或调用外部 API，绝对不要放在这里——必须移到异步任务中
跨库写日志必须显式指定数据库名
MySQL 触发器默认在当前数据库上下文执行。如果日志表在另一个库（比如 log_db.audit_log），不加库名前缀就会报 Table 'current_db.audit_log' doesn't exist。
参数差异注意：不同 MySQL 版本对跨库访问权限处理略有不同，5.7 默认允许，8.0 要求触发器定义者有目标库的 INSERT 权限，且不能是匿名用户。
实操建议：
- INSERT 日志时务必写全路径：
INSERT INTO log_db.audit_log (table_name, record_id, created_at) VALUES ('user', NEW.id, NOW()); - 触发器创建语句要用
DEFINER = 'logger'@'%'显式指定高权限账号，别依赖 CURRENT_USER() - 测试阶段用
SELECT USER(), CURRENT_USER();确认执行上下文，避免权限静默失败
真正麻烦的不是语法写不对，而是日志漏写没报警、或者写了但查不到——因为表引擎错了、库权限没给、甚至字符集不兼容导致中文变问号。这些地方一动就是线上事故，改之前最好先在影子库跑通全链路。
