在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-java 或 canal 解析变更日志——能够捕获 INSERT/UPDATE/DELETE 所有操作类型，并且精确到行级别
• 在业务层写入数据时，同步发送 MQ 消息，由消费者写入目标库——解耦性强、可审计、失败后支持重放
• 使用 pt-online-schema-change 配合触发器写入日志表——适合无法修改应用、但又需要变更捕获能力的遗留系统

当然，存储过程在临时应急或测试环境中模拟同步流程仍然有一定价值。但如果把它当作主力方案部署到线上系统，迟早会因数据不一致而付出代价，到时候可别怪没提前提醒你。