MySQL触发器可记录DML变更的OLD/NEW值，但无法捕获完整SQL、客户端IP、逻辑用户等元信息；日志表需手动创建、避免自增主键与外键，用InnoDB+COMPRESSED；AFTER INSERT中直接用NEW.id获取自增ID；日志写入失败将导致原事务回滚。
触发器能记录操作日志，但仅限于 DML 变更本身
MySQL 触发器（BEFORE INSERT、AFTER UPDATE 等）可以捕获行级变更，并把 OLD 和 NEW 值写入日志表，但它无法记录：执行语句的完整 SQL、客户端 IP、用户账号（除非显式传入）、事务上下文或执行时间戳以外的元信息。日志表必须手动建好，且触发器内不能调用存储函数获取当前登录用户（USER() 可用，但返回的是连接用户，非应用层逻辑用户）。
- 适合场景：审计关键字段变更（如
user.balance被修改）、防止误删（BEFORE DELETE拦截并记日志） - 不适用场景：全量 SQL 审计、权限溯源、慢查询分析——这些该交给
general_log或slow_query_log - 注意：触发器执行在事务内，若日志表写入失败（如磁盘满、权限不足），整个 DML 会回滚
日志表设计要避开自增主键和外键依赖
日志表应为独立、轻量、高写入容忍结构。避免用 AUTO_INCREMENT 主键（并发插入易争用），也不加外键（否则被审计表 DML 会因日志表锁而阻塞）。推荐用联合时间戳 + 随机后缀做主键，或直接用 BIGINT UNSIGNED 自增但关闭严格模式下的唯一性校验压力。
- 字段建议包含：
id（BIGINT自增）、table_name（VARCHAR(64)）、operation（ENUM('INSERT','UPDATE','DELETE')）、old_data和new_data（JSON类型，存OLD/NEW行快照）、created_at（TIMESTAMP DEFAULT CURRENT_TIMESTAMP）、host（VARCHAR(64)，来自SUBSTRING_INDEX(USER(), '@', -1)） - 引擎必须用
InnoDB（保障事务一致性），但可设ROW_FORMAT=COMPRESSED节省空间 - 不要在日志表上建全文索引或复杂查询索引——查日志应走
WHERE created_at BETWEEN ...+table_name过滤
AFTER INSERT 触发器里怎么安全读取新插入的 ID
如果主表用 AUTO_INCREMENT，在 AFTER INSERT 触发器中可用 NEW.id 直接获取刚生成的主键值；但如果主表主键是 UUID 或业务生成的，就得确保该值已在 INSERT 语句中显式提供，否则 NEW.id 为空。别试图在 BEFORE INSERT 里用 SELECT LAST_INSERT_ID()——它还没产生。
- 正确写法：
INSERT INTO log_table (table_name, operation, new_data, created_at) VALUES ('users', 'INSERT', JSON_OBJECT('id', NEW.id, 'name', NEW.name), NOW()); - 错误写法：
SET @last_id = LAST_INSERT_ID();—— 在触发器中无效，且非事务安全 - 风险点：若主表主键是
UUID()表达式，需在BEFORE INSERT中先赋值给NEW.id，否则AFTER阶段读不到
触发器日志写入失败会导致原操作失败
这是最容易被忽略的生产陷阱。触发器属于原事务一部分，一旦日志表 INSERT 报错（比如字段超长、JSON 序列化失败、磁盘空间不足），整个原始 INSERT/UPDATE/DELETE 都会回滚。线上环境务必做压测验证日志表写入稳定性。
- 缓解方式：日志表字段长度留足余量（如
JSON字段用LONGTEXT）；禁用日志表的STRICT_TRANS_TABLES模式（通过会话级设置）；定期清理旧日志（用EVENT或外部脚本） - 替代思路：高并发场景下，改用应用层异步写日志（如发 Kafka 消息），触发器只做最小必要同步动作（如标记变更状态）
- 调试技巧：临时在触发器里加
INSERT INTO debug_log VALUES (NOW(), 'trigger_fired');，观察是否真被调用，再逐步加实际逻辑
