MySQL触发器写入日志表失败会静默吞错，主语句仍成功，导致审计断档；常见原因包括日志表不存在、字段类型不匹配、权限不足或约束冲突，且错误不可见、SHOW ERRORS查不到，须用IGNORE/ON DUPLICATE KEY UPDATE兜底并精简日志表结构。
MySQL触发器写入日志表失败会静默吞掉错误
MySQL触发器里执行INSERT INTO log_table失败时，默认不报错、不中断主语句，只丢弃日志——你根本不知道它没写进去。这是最危险的“假成功”：审计断档、故障无迹可寻。
常见原因包括：log_table不存在、字段类型不匹配（比如TEXT列插入超长字符串）、权限不足（触发器以DEFINER身份运行，但该用户没INSERT权限）、或违反约束（如唯一键冲突）。这些错误在客户端完全不可见，SHOW ERRORS也查不到。
- 务必在创建日志表时显式指定
ENGINE=InnoDB，避免MyISAM因崩溃导致日志丢失 - 所有
INSERT语句必须用IGNORE或ON DUPLICATE KEY UPDATE兜底，防止约束冲突中断流程 - 日志表字段尽量精简：只存
trigger_name、table_name、operation、error_msg、created_at，避免JSON或TEXT大字段 - 测试时手动删掉日志表再跑一次DML，确认是否真报错——很多团队误以为“没报错=写成功”，其实是错误被忽略
SQL Server触发器中INSERT日志失败会导致事务卡死
SQL Server触发器里写日志失败后，如果还用了SET XACT_ABORT ON，事务状态会变成XACT_STATE() = -1：事务还在，但既不能COMMIT也不能ROLLBACK，后续任何操作都抛出“当前事务无法提交”错误。
这不是日志表的问题，而是TRY...CATCH和事务状态耦合太紧。一旦CATCH块里INSERT失败，XACT_STATE()立刻变-1，而你又没检查就直接往下走，就卡住了。
-
CATCH块第一行必须加IF XACT_STATE() != 0 ROLLBACK TRANSACTION，否则事务悬停 - 日志
INSERT语句要放在TRY内，且单独包裹一层TRY...CATCH——别让日志失败影响主逻辑 - 避免在日志
INSERT里引用视图、函数或触发其他触发器，这些都可能引发嵌套异常 - 用
ERROR_NUMBER()和ERROR_MESSAGE()捕获原始错误，但必须在CATCH开头立即存进变量，后续语句可能覆盖它们
PostgreSQL触发器写日志失败会直接回滚整个DML
PostgreSQL默认行为是：触发器里任何未捕获的错误（包括日志表INSERT失败），都会让整条INSERT/UPDATE/DELETE语句回滚。这看起来“安全”，实则掩盖了真正问题——你以为是业务逻辑错了，其实是日志表结构变更或权限丢了。
更麻烦的是，如果你在EXCEPTION块里捕获了错误但没RAISE，DML会成功提交，日志却没写进去，形成一致性缺口。
- 日志表必须提前建好，并用
GRANT INSERT ON log_table TO trigger_owner授予权限 - 在
EXCEPTION块里，优先用GET STACKED DIAGNOSTICS提取上下文，比SQLERRM更准 - 不要在
EXCEPTION里做耗时操作（如调用pg_notify发通知），否则拖慢主事务；日志写入必须轻量 - 若需确保日志必达，得用自治事务（autonomous transaction）模式，但PostgreSQL原生不支持，只能靠外部消费者轮询+重试补偿
跨数据库统一处理日志写入失败的核心原则
不管用哪种数据库，日志写入失败都不该影响主业务数据的一致性，但也不能让它悄无声息。真正的难点不在语法，而在错误边界的定义：哪些失败可以容忍，哪些必须阻断，哪些要降级记录。
- 永远把日志表当成“只写不读”的黑盒——不查、不更新、不加复杂索引，避免它反向拖累主表
- 触发器里禁止出现
SELECT ... INTO、临时表或变量声明嵌套，这些语法容易在不同版本间失效 - 上线前必须模拟日志表损坏场景：rename表名、删字段、改权限，验证主DML是否仍能完成
- 最易被忽略的是时区和字符集：日志表
created_at字段用TIMESTAMP而非DATETIME，避免MySQL中NO_ZERO_DATE模式下插入失败
