SQL触发器无法实现主从表“自动平衡”，仅能响应单条DML操作，不校验终态、不可绕过且无法修复跨事务/批量/顺序错误；真正一致性需靠外键、应用层事务、离线校验与变更日志等分层机制。
触发器无法真正实现主从表“自动平衡”
直接说结论：SQL 触发器不是为“数据平衡”设计的，它只能响应单条 DML 操作（INSERT/UPDATE/DELETE），无法感知跨事务、跨会话或批量操作后的最终状态。所谓“自动平衡”，比如主表删了 10 行但从表漏删 2 行、或从表多插入了脏数据——触发器对此无能为力，因为它不扫描全表，也不校验终态。
AFTER INSERT/UPDATE/DELETE 触发器只做“即时反应”，不做“兜底修复”
你写一个 AFTER DELETE ON orders 触发器去删 order_items，这没问题；但如果有人绕过触发器（如用 DISABLE TRIGGER、直接 truncate 从表、或应用层直连 bypass 权限），一致性就立刻破裂。更常见的是：业务逻辑里先删从表再删主表，结果主表删失败回滚，但从表已删——触发器救不了这种顺序错误。
实操建议：
- 触发器只用于强耦合、不可绕过的简单级联动作（如自增统计字段、日志快照）
- 避免在触发器里调用存储过程或远程服务，否则事务阻塞风险高
- PostgreSQL 的
FOR EACH STATEMENT比FOR EACH ROW更轻量，适合汇总类更新 - MySQL 8.0+ 支持
SET FOREIGN_KEY_CHECKS = 0绕过外键，但也会跳过对应触发器——这点常被忽略
真要“平衡”，得靠外部机制，触发器顶多当个“守门员”
生产环境保障主从一致，实际靠的是分层策略：
- 数据库层：用
FOREIGN KEY约束（带ON DELETE CASCADE）比触发器更可靠、性能更好 - 应用层：所有写操作走统一 DAO，用事务包裹主从变更，失败则整体回滚
- 离线校验：每天跑一次
SELECT COUNT(*) FROM master LEFT JOIN slave...对比行数，或用 checksum 工具（如 pt-table-checksum）定位差异 - 变更日志：基于 binlog / wal 解析做最终一致性补偿（如用 Debezium + Kafka + Flink 重放）
触发器在这里的角色，只是防止最基础的手工误操作，比如 DBA 在命令行直接 DELETE FROM users 却忘了清空 user_profiles。
一个典型陷阱：INSTEAD OF 触发器在视图上容易掩盖约束失效
有人试图用视图 + INSTEAD OF INSERT 把主从插入“封装”起来，以为这样就能控制流程。问题在于：一旦视图定义漏掉某个从表字段、或触发器内部没做 ROLLBACK，错误会被静默吞掉。更糟的是，这类触发器在 PostgreSQL 中不支持修改多个基表，在 SQL Server 中对 INSERT ... SELECT 行为不一致。
如果你真写了这样的触发器，请务必测试以下场景：
- 插入时从表字段为
NOT NULL但触发器没提供默认值 → 报错NULL value inserted into NOT NULL column - 触发器里执行
INSERT INTO slave VALUES (...)失败，但主表INSERT已提交 → 数据撕裂 - 并发插入相同主键 → 触发器可能因未加锁导致重复插入从表
真正难的从来不是写触发器，而是想清楚：哪一层该负责哪部分一致性。数据库不替你做业务判断，它只保证自己语句的原子性。
