先说一个明确结论：利用存储过程实现增量同步确实可行，但它的适用场景远比想象中有限。这种方式仅适合低频、小规模、非核心链路的同步任务——一旦应用于关键业务系统，大概率会出现严重问题。最关键的是，存储过程无法捕获 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配合触发器写入日志表——适合无法修改应用、但又需要变更捕获能力的遗留系统
当然，存储过程在临时应急或测试环境中模拟同步流程仍然有一定价值。但如果把它当作主力方案部署到线上系统，迟早会因数据不一致而付出代价，到时候可别怪没提前提醒你。
