PHP增量同步首选binlog（需ROW格式+REPLICATION权限），次选时间戳（须确保更新必写且无时钟问题）；二者选型取决于延迟要求、运维能力及目标存储事务支持。
PHP 读取 MySQL binlog 实现增量同步的关键前提
直接用 PHP 解析 MySQL binlog 是可行的，但必须满足：MySQL 开启 binlog_format=ROW（STATEMENT 或 MIXED 模式下无法可靠获取变更行数据），且用户拥有 SUPER 或 REPLICATION SLAVE 权限。PHP 本身不内置 binlog 解析器，需依赖第三方库如 php-mysql-replication —— 它基于 MySQL 协议模拟从库，实时拉取并解析 binlog event。
常见错误现象：Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s)，或解析出的 WriteRowsEvent 中 rows 为空，基本都是 binlog_format 不对或表无主键导致。
- 务必在目标库执行
SHOW VARIABLES LIKE 'binlog_format';确认返回ROW - 同步前检查所有待同步表是否含主键，否则
UpdateRowsEvent和DeleteRowsEvent可能丢失旧值或定位失败 - 首次启动时需提供
binlog filename和position（可用SHOW MASTER STATUS获取），跳过历史日志可大幅降低初始化压力
用时间戳字段做增量同步的适用边界与陷阱
当无法开启 binlog 或权限受限时，时间戳（如 updated_at）是更易落地的替代方案，但它只适用于「写操作必更新该字段」且「应用层无延迟写入、跨时区或时钟漂移」的场景。一旦出现 updated_at 未被业务逻辑更新、或定时任务批量回刷旧数据，就会漏同步或重复同步。
典型问题：凌晨跑批任务将十万条记录的 updated_at 统一设为当前时间，导致下游系统误认为这是新变更而全量重推。
立即学习“PHP免费学习笔记（深入）”；
- 必须确保数据库字段类型是
DATETIME或TIMESTAMP，避免用INT存秒级时间戳——PHP 读取时易因时区转换错位 - 查询语句必须加
WHERE updated_at > ? ORDER BY updated_at, id，否则并发拉取时可能因写入顺序和查询顺序不一致导致跳过记录 - 每次同步完成后，应持久化本次最大
updated_at值（推荐存到独立配置表而非文件），防止进程崩溃后从头重跑
PHP 中处理 binlog event 的核心逻辑要点
php-mysql-replication 库暴露的事件对象（如 WriteRowsEvent）包含 table、schema、rows 等属性，但 rows 是嵌套结构，需手动展开成标准数组才能插入目标库。重点不是“怎么解析”，而是“怎么映射”和“怎么幂等”。比如源表 user(id, name, email) 和目标表字段名不同，或需过滤敏感字段，都得在 event 处理阶段完成。
- 不要在
WriteRowsEvent回调里直接执行 INSERT —— 需先格式化为关联数组，再交由统一的写入函数处理，便于加事务、重试、字段映射 - 对
DeleteRowsEvent，优先使用主键构造WHERE id = ?删除，而非依赖before_image全字段匹配，避免因字段缺失或 NULL 导致删错 - 遇到
UpdateRowsEvent，应比对before和after差异，仅同步实际变更字段，减少下游压力
binlog 同步与时间戳同步的选型判断点
真正决定方案的不是技术炫酷度，而是运维可控性和故障恢复成本。binlog 方案延迟低（毫秒级）、不侵入业务，但依赖 DBA 配合，且一旦主库重启或 binlog 被 purge，位置信息丢失就得人工介入；时间戳方案完全由应用控制，重启即续，但天然有窗口期（比如每分钟拉一次，就最多丢 60 秒数据），且无法捕获物理删除（如 DROP TABLE）。
一个常被忽略的细节：如果目标库是 Elasticsearch 或 ClickHouse 这类不支持事务的存储，binlog 的 event 顺序必须严格保证——php-mysql-replication 默认单线程消费，但若自行多进程分发 event，顺序就无法保障，此时时间戳 + 单点调度反而是更稳的选择。
