用存储过程做增量同步不可行，因其无状态、不感知binlog、无法捕获delete/update旧值、不保证事务一致性，仅适用于低频小规模非关键场景；必须依赖时间戳或自增id字段（如timestamp on update current_timestamp或bigint主键）作为增量标识，并通过ifnull/coalesce处理空值、严格使用>比较、手动维护sync_status表来规避重复与漏同步问题。
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配合触发器写日志表 —— 适合不能改应用、又需要变更捕获的老系统
存储过程适合临时救急或测试环境模拟同步流，但上线系统里把它当主力方案，迟早踩坑在数据不一致上。
