MySQL存储过程实现数据增量同步

直接结论：利用存储过程实现增量同步确实可行，但实际效果远非理想。它仅适用于低频、小规模且非关键链路的场景。一旦用于核心业务，极易出现问题。最关键的是，存储过程无法捕获 DELETE 或 UPDATE 的旧值，不感知 binlog，也无法保证事务一致性。因此，不应将其作为主备同步方案。

为什么必须用时间戳或自增ID字段做判断

存储过程本身不记录状态，每次调用都是无状态重试。它只能通过查询目标表已存在的最大值来推断上次同步位置。如果源表没有维护 created_at 或 updated_at 字段，SELECT ... WHERE 条件将无从构建。

• 推荐字段类型：TIMESTAMP（带 ON UPDATE CURRENT_TIMESTAMP）或 BIGINT 自增 ID（需确保插入顺序与业务逻辑一致）
• 避免使用 DATETIME 配合 NOW() ——时区不一致时，极易遗漏数据
• 若源表已存在数据但缺少时间戳字段，需先执行 ALTER TABLE ... ADD COLUMN，再批量补值。否则历史数据将永远无法同步

INSERT ... SELECT 里最容易漏掉的边界条件

看似一条简单 SQL，实际常因边界值而出错。例如目标表为空时，MAX(sync_time) 返回 NULL，导致整个 WHERE 条件失效，新数据无法写入。因此嵌套条件成为必要：

• 必须使用 IFNULL(MAX(sync_time), '1970-01-01 00:00:00') 或 COALESCE 处理空值
• 时间字段比较应采用严格大于（>），而非大于等于（>=），否则会造成重复插入
• 如果源表有 ON DUPLICATE KEY UPDATE 需求，存储过程中需改用 INSERT ... ON DUPLICATE KEY UPDATE，同时确保主键或唯一索引已定义且清晰

调用前必须手动维护的“上次同步状态”

MySQL 存储过程不会自动记录执行状态，每次 CALL IncrementalSync() 都是无状态重试。这意味着：

• 若中途失败（网络中断或锁表超时），无法准确定位同步卡顿点
• 无法跳过已处理的 binlog event，也无法回滚部分插入。尽管 INSERT ... SELECT 是原子操作，失败后仍需人工清理脏数据
• 如需加入重试逻辑，需额外创建 sync_status 表，存储 last_sync_time 和 executed_at，并在存储过程开头显式执行 UPDATE

比存储过程更靠谱的替代路径

对于真正落地的增量同步，优先考虑以下方案：

• 开启 binlog_format = ROW，利用 mysql-binlog-connector-ja va 或 canal 解析变更——可捕获 INSERT/UPDATE/DELETE 全部类型，精度至行级别
• 业务层写入数据时同步发送 MQ 消息，由消费者落库——解耦性强、可审计、失败可重放
• 使用 pt-online-schema-change 配合触发器写入日志表——适用于无法修改应用但需要变更捕获的老系统

当然，存储过程在临时救急或测试环境模拟同步流仍有一定价值。但若将其作为线上主力方案，迟早会遭遇数据不一致问题，届时后果需自行承担。