<p>“找不到起始GTID”本质是--start-position未对齐到GTID事件开头，需用mysqlbinlog -v配合grep定位合法# at位置；--skip-gtids=true仅适用于恢复至已有GTID历史的实例；--start-datetime受时区影响，应优先使用位置定位。</p>
mysqlbinlog报错“找不到起始GTID”本质是位置不匹配
这不是GTID真丢了，而是你给mysqlbinlog指定的--start-position落在了事务中间，或压根没对齐到Gtid_log_event开头。MySQL要求GTID模式下所有重放必须从完整的GTID事件开始，否则解析器直接报错退出，常见错误如ERROR 1782 (HY000)：“@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON”。
怎么快速定位合法的GTID起始位置
别靠猜，用mysqlbinlog自己查：
- 先解析目标binlog：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -E "^#.*GTID.*uuid|^# at" - 找形如
# at 648+ 紧跟其后的SET @@SESSION.GTID_NEXT='xxx:yyy'这一对行——648就是合法起始pos - 如果
--start-position=713报错，但648能过，说明713落在了前面那个Query事件内部（比如建表语句中间），不是GTID边界 - 注意：
SHOW BINLOG EVENTS里看到的Pos列值，就是# at后那个数字，可直接复用
--skip-gtids=true不是万能钥匙，用错反而锁死恢复
这个参数只在特定场景有效，滥用会导致GTID集合冲突：
- 恢复到**原库或已有相同GTID历史的实例**时，必须加
--skip-gtids=true，否则重复GTID被拒绝执行 - 恢复到**全新实例（空GTID_EXECUTED）**，不加该参数更安全；加了反而可能让
Executed_Gtid_Set变成0-0，后续同步出问题 - 如果dump文件里带
SET @@GLOBAL.GTID_PURGED，而目标库GTID_EXECUTED非空，会报ERROR 1840——此时应改用mysqldump --set-gtid-purged=off重新导出，而不是硬加--skip-gtids
最容易被忽略的时区陷阱
--start-datetime参数默认按系统本地时区解析，但binlog里时间戳存的是UTC。若MySQL的system_time_zone和系统时区不一致（比如MySQL设为Asia/Shanghai，而系统是UTC），你指定"2024-06-15 14:22:00"实际可能对应binlog里14:22:00 UTC，也就是北京时间22:22，差整整8小时。
安全做法是：先用mysqlbinlog -v人工确认目标事件的真实SET TIMESTAMP=值，再换算成对应时区下的准确时间点，或干脆放弃--start-datetime，专注用--start-position+GTID定位。
