mysql触发器中禁止对触发表执行任何读写操作，包括select；应显式列出字段记录日志，优先使用after触发器并确保日志表为innodb引擎，避免过度索引，且触发器无法捕获绕过sql层的修改。
触发器里不能用 INSERT ... SELECT 直接读当前表
想在 UPDATE 触发器里把旧值记到日志表，顺手写 INSERT INTO audit_log SELECT OLD.* FROM users WHERE id = OLD.id —— 这会报错 ERROR 1442 (HY000): Can't update table 'users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。MySQL 禁止在触发器中对触发它的同一张表做任何读写（哪怕只是 SELECT），本质是防止递归和死锁。
实操建议：
- 所有要记录的字段必须显式列出，比如
INSERT INTO audit_log (table_name, action, user_id, old_name, new_name, updated_at) VALUES ('users', 'UPDATE', OLD.id, OLD.name, NEW.name, NOW()) - 如果字段多、易变，提前建好视图或用应用层拼 SQL，别指望触发器自动反射结构
-
OLD和NEW是只读临时引用，不能赋值、不能调函数、不能嵌套子查询
AFTER INSERT 比 BEFORE INSERT 更适合记操作时间
用 BEFORE INSERT 记日志，NOW() 或 CURRENT_TIMESTAMP 可能和主表插入时间不一致（尤其批量插入时），而且如果主表插入因约束失败回滚，BEFORE 里的日志却已落盘，造成日志孤岛。
实操建议：
- 统一用
AFTER类型触发器：日志写入与主表变更原子性绑定，要么都成功，要么都失败 - 日志表必须用
ENGINE=InnoDB，否则无法参与事务；别用MyISAM，它不支持事务，日志会“逃逸” - 如果真需要记录“准备插入但被拒绝”的行为（比如权限拦截），那得靠应用层或代理层，触发器做不到
日志表设计不当会导致主表写入变慢三倍以上
常见错误是给日志表加一堆索引：比如对 user_id、action、created_at 全部单独建索引，甚至加全文索引。每条主表变更都会同步更新这些索引，I/O 压力直接翻倍。
实操建议：
- 日志表只保留必要字段，避免
TEXT或大JSON字段；历史快照类数据尽量压缩后存为MEDIUMTEXT并关闭索引 - 索引只建复合索引
(table_name, action, created_at)，覆盖最常用查场景；单列索引一律不要 - 定期归档：用
ALTER TABLE audit_log RENAME TO audit_log_202406+ 新表重建，比DELETE快得多，也避免长事务锁表
触发器无法捕获应用层绕过 SQL 的修改
如果业务用了 ORM 的 raw query、跳过模型直接 UPDATE users SET name='x' WHERE id=1，或者用 LOAD DATA INFILE 批量导入，触发器依然生效；但如果走的是 MySQL Router、ProxySQL 的改写规则，或直接操作存储引擎文件（极端情况），触发器就完全失效。
实操建议：
- 触发器只是兜底手段，关键操作必须在应用层埋点（如记录
request_id、operator_id） - 审计强需求场景，启用 MySQL 官方企业版的
Audit Log Plugin或 Percona 的audit_log插件，它们能捕获连接、命令、参数级日志 - 开发期就禁用
SUPER权限给业务账号，防止有人用SET sql_log_bin=0绕过 binlog 和触发器
触发器不是黑盒审计开关，它依赖 SQL 路径、受事务边界约束、对高并发写敏感——日志准不准，先看触发器有没有被真正执行到。
