MySQL 触发器不能替代主从复制或逻辑复制
触发器本身不参与 MySQL 的复制机制，它只在本地执行。即使你建了
AFTER INSERT触发器去写另一张表，这个操作默认不会被 binlog 记录（除非显式开启
log_bin_trust_function_creators=1且触发器是确定性的），更不会自动同步到从库。主从复制靠的是 binlog event 的重放，不是靠触发器“推”数据。
常见错误现象：
INSERT INTO orders在主库触发了更新
stats_summary表的触发器，但从库的
stats_summary没变——因为触发器没在从库运行，且该更新未进 binlog。 触发器修改的数据，只有显式写入语句（如
INSERT/UPDATE/DELETE）才会进入 binlog，默认模式下触发器内部的 DML 不记日志 若用
STATEMENT格式 binlog，非确定性触发器可能在从库执行出错或结果不一致
ROW格式 binlog 下，触发器产生的变更仍不会被记录——binlog 只记录原始语句影响的行，不记录触发器额外改的行
想用触发器做跨表/跨库同步？必须手动控制 binlog 记录
如果真要靠触发器“辅助同步”，比如主表插入后自动往另一个数据库的汇总表写一条记录，那得确保这条写操作能进 binlog 并被下游消费。这要求：
目标表必须和触发器所在表在同一个实例（跨实例无法用触发器直接写，会报ERROR 1442 (HY000)） 触发器内不能调用存储函数或过程，除非它们被标记为
DETERMINISTIC且用户有
SUPER权限（已弃用）或已设置
log_bin_trust_function_creators=1更稳妥的做法是：触发器不直接写目标表，而是写一张本地“同步队列表”，再由外部工具（如 Debezium、Canal 或自研脚本）监听这张表的 binlog，投递到目标系统
CREATE TRIGGER sync_orders_to_summary
AFTER INSERT ON orders
FOR EACH ROW
INSERT INTO sync_queue (table_name, op, pk_id, created_at)
VALUES ('orders', 'INSERT', NEW.id, NOW());
触发器 + 延迟复制 + 从库只读？小心数据不一致放大
有人尝试在从库上建触发器，想“补全”主库没同步过来的逻辑（比如自动填充字段）。这是危险操作：
ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is being used by statement which invoked this stored function/trigger—— 从库应用 binlog 时处于只读状态，触发器若尝试写表会直接失败，导致 SQL 线程中断。
即使绕过（比如用
init_connect或中间件拦截），也会破坏复制一致性：主库没做的事，从库自己做了，后续主库一旦补数据或修复，就会冲突。 从库加触发器属于“写偏离”，MySQL 复制协议不保证这种操作可逆或幂等 延迟复制（
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = N）只是给个时间窗口，不能用来“等触发器慢慢追平” 真正需要定制化同步逻辑，应该放在复制链路的消费者端（如 Flink CDC、Maxwell），而不是塞进 MySQL 内核流程
替代方案比硬套触发器更可靠
如果你的目标是“某张表变更后，立刻让另一张表/服务感知”，优先考虑这些路径：
业务代码里显式双写：INSERT INTO orders和
INSERT INTO summary放在一个事务里（注意跨库事务需 XA 或最终一致性补偿） 用
mysqlbinlog解析 + 自定义消费者，监听指定表的 row event，过滤后转发到目标库或消息队列 启用
GENERATED COLUMN或
VIRTUAL COLUMN实现只读派生字段，避免冗余存储 对统计类场景，用物化视图（MySQL 8.0.23+ 的
CREATE MATERIALIZED VIEW预览版）或定期跑
INSERT ... SELECT批量刷新
触发器真正的适用场景很窄：单实例内、强事务一致性要求、逻辑简单、不涉及复制传播——比如自动填充
created_at、检查约束、记录操作日志到本地 audit 表。把它当成同步基础设施，等于在复制管道里焊了个不标压力值的阀门。
