最常用且可控的跨表同步方式是INSERT INTO...SELECT，适合一次性补全、定时快照等场景，但非实时；触发器适用于写即同步，事件+存储过程适合定时增量同步；主从复制不适合表级业务同步。
直接同步两个表，不用写脚本、不搭主从，最常用且可控的方式是用 INSERT INTO ... SELECT 配合权限和结构适配。它适合一次性补全、定时快照、跨库迁移等场景，但不是实时复制。
用 INSERT INTO ... SELECT 做单次或定时同步
这是纯 SQL 实现跨表同步的基石，核心在于 SELECT 部分可自由加工源数据，INSERT 部分明确目标列。
常见错误现象：
-
Column count doesn't match：源 SELECT 列数与目标 INSERT 列数不一致 -
Truncated incorrect DOUBLE value：类型隐式转换失败，比如把字符串 '2024-01' 当成数字参与计算 - 权限报错
ERROR 1142 (42000): SELECT command denied或INSERT command denied：执行账号缺对应库表权限
实操建议：
- 必须显式写出目标列名，避免依赖字段顺序：
INSERT INTO db_b.t2 (id, name, created_at) SELECT id, user_name, add_time FROM db_a.t1 - 跨库时直接用
db_name.table_name写法，无需 USE 切库 - 字段名不一致？用
AS重命名：SELECT name AS full_name, age AS user_age FROM t1 - 类型不匹配？用
CAST(col AS CHAR)或CONVERT(col, DATE)显式转换 - 目标表有自增主键且不想覆盖？SELECT 中跳过该列，或确保值为
NULL（取决于sql_mode）
用触发器实现“写即同步”
当源表写入频繁、且每次变更都必须立刻反映到目标表时，TRIGGER 是轻量级选择。但它只响应 DML，不处理 DDL，也不保证跨库事务一致性。
使用场景：
- 日志归档：对操作表
t1的每条 INSERT，自动写入审计表log_t1 - 缓存表维护：源表更新后，同步刷新一张宽表用于报表查询
容易踩的坑：
- 触发器不能跨库调用存储过程，也不能在触发器里再 INSERT 到另一个远程库（MySQL 不支持）
- 触发器内禁止使用
SELECT ... FOR UPDATE或其他显式锁语句 - 如果目标表也在同一实例，注意循环触发风险（比如 A 触发 B，B 又触发 A）
-
NEW和OLD只在行级触发器中可用，语句级（FOR EACH STATEMENT）不支持
示例（同库同步）：
CREATE TRIGGER sync_t1_to_t2 AFTER INSERT ON t1 FOR EACH ROW INSERT INTO t2 (id, title, ts) VALUES (NEW.id, NEW.subject, NOW());
用事件 + 存储过程做定时增量同步
比触发器更可控，适合每天/每小时跑一次的准实时同步，尤其当源表有时间戳字段（如 updated_at）时。
关键参数差异：
-
EVENT默认被禁用，需先执行SET GLOBAL event_scheduler = ON; - 存储过程中不能直接用
SELECT ... INTO OUTFILE，但可以用INSERT ... SELECT+WHERE updated_at > last_sync_time - 事件调度器不感知会话变量，所有时间条件必须固化在 SQL 或查配置表获取
实操建议：
- 建一张
sync_log表记录每次执行的max_updated_at，下次作为起点 - 用
INSERT IGNORE或ON DUPLICATE KEY UPDATE处理重复主键冲突 - 避免在高峰期执行大范围 UPDATE/INSERT，加
LIMIT分批处理（需配合游标或子查询）
为什么不用主从复制来同步两个表？
主从复制是实例级同步机制，不是表级工具。即使你只配了 replicate-wild-do-table=db.t1，它仍要求：
- 主库开启
log_bin，从库开启relay_log - 两库版本尽量一致（尤其 MySQL 5.7 → 8.0 有兼容风险）
- 无法做字段映射、类型转换、逻辑过滤（比如只同步 status=1 的行）
- 一旦从库写入脏数据，
START SLAVE可能直接报错中断
换句话说：主从适合“整库镜像”，不适合“两张表按业务规则对齐”。真要这么做，不如用 mysqldump --where="status=1" 导出再导入，还更可控。
真正难的不是语法，而是判断同步时机和容错边界——比如触发器失败是否丢数据、定时任务卡住是否堆积、跨库权限是否随账号轮换失效。这些细节不会报错，但会在某次上线后突然暴露。
