如何实现SQL分表数据同步？通过触发器映射写入目标表
触发器能直接跨库写入目标分表吗？
答案是：不能。这事儿在MySQL 5.7及之前的版本里，基本是条死胡同。无论是BEFORE还是AFTER触发器，都不支持直接向另一个数据库执行INSERT操作。当然，你可能会想到用FEDERATED引擎表作为“跳板”，或者给目标表在当前库建个别名，但前者早已被官方弃用且极不稳定，后者本质上还是在操作同一个库。即便你升级到了MySQL 8.0+，试图在触发器里调用一个能跨库写的存储过程，也会立刻撞上SQL SECURITY DEFINER的权限墙和二进制日志格式的种种限制，稍有不慎就会导致主从复制中断或数据不一致，风险极高。
一个典型的报错长这样：ERROR 1442 (HY000): Can't update table 't_shard_01' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这通常意味着，触发器试图去修改的“另一张”表，其实正被触发它的主SQL语句以某种方式锁定或访问，权限或事务隔离级别根本不答应。
- 作用域是硬伤：触发器的活动范围被严格限定在它所属的数据库内。定义触发器的用户，默认只能操作同库的对象。
- 显式指定也未必管用：就算你用了
db_name.table_name这种完整写法，MySQL内核，尤其是在使用ROW格式的binlog时，依然可能直接拒绝执行。 - 触发时机有盲区：别忘了，触发器对DDL操作（比如ALTER TABLE）或TRUNCATE是无感的。同样，如果外部应用通过特定方式（例如某些JDBC驱动的批量插入优化）直接写入，也可能完美绕过触发器的监控。
替代方案：用 AFTER INSERT 触发器 + 写入本地中间表
那么，靠谱的路子究竟在哪？其实思路很简单：让专业的人做专业的事。触发器只负责它最擅长的那部分——感知数据变化，并把变更记录“扔”到同一个数据库里的一张轻量级中间表（比如叫sync_queue）里。至于跨库、跨表、分片路由这些复杂的同步逻辑，则交给外部的专业同步服务（比如一个Python脚本、Go语言写的Worker，或者Canal这类中间件）去异步消费和处理。这样既完美绕开了触发器的所有限制，又能在最大程度上保证数据的实时性。
来看一个中间表示例结构：
CREATE TABLE sync_queue (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
src_table VARCHAR(64) NOT NULL,
src_id BIGINT NOT NULL,
op_type ENUM('INSERT','UPDATE','DELETE') NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
processed TINYINT DEFAULT 0,
KEY idx_unproc (processed, created_at)
);
- 触发器要做的事极其简单：配置一个
AFTER INSERT触发器，每当源表有数据插入，就往sync_queue表里插入一条对应的记录，仅此而已，完全不触碰目标分表。 - 保持触发器轻量：切忌在触发器中嵌入复杂的业务逻辑，比如JSON序列化、甚至发起远程HTTP请求。这些操作会严重拖慢主业务表的写入速度，成为性能瓶颈。
- 中间表设计是关键：
processed字段（用于标记是否已处理）和相应的索引（如示例中的idx_unproc）必不可少。如果没有它们，消费端每次都要做全表扫描来查找未处理的任务，延迟飙升是分分钟的事。
为什么不能用 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE 同步分表？
有些朋友可能会想：既然触发器写不过去，那在消费程序里用REPLACE INTO或者INSERT ... ON DUPLICATE KEY UPDATE这种“智能插入”语句来同步分表，行不行？很遗憾，在分表场景下，这条路也基本走不通。
核心矛盾在于：分表键（例如 user_id % 4）和表上的主键或唯一键，往往不是一回事。当你尝试REPLACE INTO t_shard_02时，如果目标分表上没有与数据匹配的唯一索引，这条语句就会退化成普通的INSERT，完全失去了“替换更新”的功能。如果你为了用这个语法，强行在所有分表上都创建一个业务主键的唯一索引，又会带来新的麻烦：一旦分片规则需要调整，极易引发唯一键冲突，甚至导致数据丢失。
- 主键不“唯一”：分表之后，每个子表通常使用独立的自增ID作为主键，这个ID只在当前分片内唯一，全局来看是重复的，根本无法作为数据同步的判重依据。
- 业务主键的困境：即使你有像订单号（order_no）这样的业务主键，如果它没有在所有分表上建立唯一索引，那么
ON DUPLICATE KEY UPDATE子句压根不会被触发。 - 并发写入的隐患：退一步讲，就算建了唯一索引，在高并发多线程同时写入同一个分表时，这类“插入或更新”语句比单纯INSERT的锁范围更大，更容易导致死锁，让问题复杂化。
生产环境必须检查的三个同步一致性点
触发器加上中间表，只是搭建了同步链路的第一环。真正决定数据最终是否一致的，是下游的消费逻辑和整个流程的幂等性设计。这里有一个极易被忽略的认知误区：主库写入成功，绝不等于同步完成。很多应用层逻辑错误地认为，数据插进去就万事大吉了。
- 事务原子性是底线：向中间表
sync_queue插入记录的操作，必须与源表的INSERT操作在同一个数据库事务内（用START TRANSACTION包裹起来）提交。否则，源表写入成功，队列记录却没写进去，这个“变更事件”就彻底丢失了。 - 消费端要防重入：消费程序在从中间表取任务时，一定要使用
SELECT ... FOR UPDATE SKIP LOCKED这类语法。这能确保多个消费Worker不会同时抢到并处理同一条记录，实现安全的并发消费。 - 失败处理不能静默：向目标分表写入失败时，绝对不能简单地跳过或丢弃。必须将失败记录落盘到专门的
sync_error_log表，并设计人工干预和重试的机制。因为分表之间，哪怕只是字段默认值、一个约束的微小差异，都可能导致插入静默失败。
说到底，触发器本身是轻量级的，但整个同步链路的可靠性，取决于其中最薄弱的那一环。中间表的结构变更、消费进程意外设掉、目标数据库网络闪断、甚至服务器之间时钟不同步导致created_at排序错乱……这些问题如果不提前进行充分的压测和预案设计，上线之后，它们一定会在你最意想不到的时间和地点冒出来。
