单靠SQL触发器无法真正防止财务数据篡改，它仅能在BEFORE UPDATE中校验数据合法性（如salary越界、状态非法跳转），但拦不住合法权限下的恶意修改；不可逆审计日志必须用AFTER触发器写入独立日志表，并保障事务一致性。
单靠 SQL 触发器无法真正“防止”财务数据篡改，它只能在 UPDATE 语句执行前做合法性校验；而不可逆审计日志必须用 AFTER 触发器 + 独立日志表 + 事务一致性保障，否则要么漏记、要么拖垮业务。
BEFORE UPDATE 触发器只校验，不防人
你在 BEFORE UPDATE 里用 SIGNAL SQLSTATE '45000' 拦住的，仅限明显违规的数据变更，比如：
-
salary被设为负数或超 9999999 -
status从'paid'直接跳到'refunded'，跳过了'reviewing' -
updated_at被手动往前写（如设为 '2020-01-01'）
但它对以下情况完全无效：
- DBA 用 root 执行
UPDATE finance_ledger SET amount = 999999 WHERE id = 123—— 语句合法，权限够，触发器无权拒绝 - 应用层传入伪造的
@current_user_id = 999，再更新approved_by字段 - 通过 ETL 工具批量导入，绕过所有应用逻辑和会话变量
别把权限判断塞进触发器。CURRENT_USER() 返回的是连接账号（如 'app@10.0.2.%'），不是真实操作人；触发器也读不到 JWT、session ID 或 HTTP header。
AFTER INSERT/UPDATE/DELETE 才能写可靠审计日志
要让每一次财务变更都“留痕”，必须用 AFTER 触发器，原因很实在：
-
BEFORE阶段OLD和NEW可读但主表尚未落盘，万一触发器出错，整个事务会回滚——你既没改成功，也没留下日志 -
AFTER阶段主表已提交，OLD/NEW仍可用（MySQL 8.0+、PostgreSQL 全支持），此时写日志失败也不影响业务（只要做好错误兜底） - 日志表必须独立建库（如
audit_db），避免和业务表争磁盘 I/O 和锁资源
示例（MySQL）：
CREATE TRIGGER tr_finance_ledger_after_update
AFTER UPDATE ON finance_ledger
FOR EACH ROW
INSERT INTO audit_db.ledger_audit_log (
table_name, operation_type, old_data, new_data, operated_by, operate_time
) VALUES (
'finance_ledger',
'UPDATE',
JSON_OBJECT('id', OLD.id, 'amount', OLD.amount, 'status', OLD.status),
JSON_OBJECT('id', NEW.id, 'amount', NEW.amount, 'status', NEW.status),
COALESCE(@current_app_user, CURRENT_USER()),
NOW(3)
);
注意：COALESCE(@current_app_user, CURRENT_USER()) 是 fallback 策略，真实场景中应由应用在事务开始前显式设置 @current_app_user。
审计表结构与性能陷阱
一张设计不当的审计表，会让财务系统响应变慢甚至卡死。关键约束如下：
- 字段只存必要信息：至少含
table_name、operation_type、old_data、new_data（JSON 类型）、operated_by、operate_time - 禁用所有非关键索引；只建一个复合索引：
(operate_time, table_name, operation_type) - 字符集必须统一为
utf8mb4，排序规则用utf8mb4_unicode_ci，否则 JSON 中 emoji 或中文可能被截断 - 不要在触发器里调用
UUID()、JSON_OBJECT()以外的函数，尤其避免子查询或外部调用
如果日均审计量超 50 万行，就该考虑异步方案：MySQL 用 BLACKHOLE 引擎暂存日志，由外部服务消费；PostgreSQL 用 pg_notify() 推送事件。
DDL 操作和高危行为无法靠 DML 触发器覆盖
财务数据真正的风险点，往往不在日常 UPDATE，而在：
DROP TABLE finance_ledgerTRUNCATE TABLE finance_ledgerGRANT ALL ON finance_ledger TO hacker
这些 DDL 操作不会触发任何 INSERT/UPDATE/DELETE 触发器。应对方法是：
- MySQL：启用
audit_log插件（企业版或 Percona Server），过滤DROP、TRUNCATE、GRANT关键词，输出到 Syslog - SQL Server：用 DDL 触发器 +
EVENTDATA()捕获，并写入专用 DDL 审计表（必须异步） - PostgreSQL：启用
pg_audit扩展，配置audit_table和audit_role
所有 DDL 审计日志禁止同步写入，否则一个 TRUNCATE 就能让整个数据库 hang 住。
最易被忽略的一点：上线前必须用真实财务流水压测触发器吞吐。很多团队只测单条 UPDATE，结果上线后批量修正数据时，审计表写入延迟飙升至秒级——因为没考虑 JSON_OBJECT() 在大批量场景下的 CPU 开销，也没给 audit_db 单独配 SSD 存储。
