主从同步中断后应先检查SHOW SLAVE STATUS\G中的Relay_Master_Log_File和Exec_Master_Log_Pos，并与主库SHOW MASTER STATUS的File和Position对比，若不一致则存在延迟或中断；需关注Slave_SQL_Running状态，避免忽略SQL线程停止；GTID模式下应使用Executed_Gtid_Set和Retrieved_Gtid_Set判断同步位置，而非position；跳过错误事务时须用mysqlbinlog解析确切下一个事件起始pos，禁用sql_slave_skip_counter；binlog position不等于文件大小，因含元数据和event header。
主从同步中断后怎么快速定位 binlog 位置不一致
直接看 SHOW SLAVE STATUS\G 里的 Relay_Master_Log_File 和 Exec_Master_Log_Pos，这两个值代表「从库实际执行到的主库 binlog 文件和位置」；再登录主库执行 SHOW MASTER STATUS，对比 File 和 Position。只要两者不完全相等，就说明有延迟或已断开同步。
常见错误现象：从库 Seconds_Behind_Master 显示 NULL 或一直为 0，但数据就是没更新——大概率是 SQL 线程已停止，Slave_SQL_Running: No 却被忽略。
- 别只盯
Read_Master_Log_Pos，它只反映 IO 线程拉到了哪，不代表执行了 - 如果主库已切换过 binlog 文件（比如
mysql-bin.000012→mysql-bin.000013），而从库还卡在旧文件末尾，Exec_Master_Log_Pos就会远小于主库当前Position - 注意时区和系统时间偏差：主从服务器时间差超过 1 秒，可能让基于 GTID 的自动定位失效（尤其 MySQL 5.7 默认开启 GTID）
手动跳过错误时 change master to 的 position 怎么填才安全
跳过一个事务，不能简单把主库当前 Position 加 1，binlog 是变长格式，必须用 mysqlbinlog 解析出确切的下一个事件起始位置。
使用场景：主库执行了 DROP TABLE，但从库该表已被误删，SQL 线程报 error 1032: Can't find record，此时需要跳过这个事件继续同步。
- 先在主库查出出错事务对应的 binlog 文件和偏移量：
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000012 | grep -A 20 "end_log_pos 12345" - 找到该事件后的
end_log_pos值（比如 12489），这就是下一条事件的起始位置 - 停从库：
STOP SLAVE;，再执行：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=12489; - 切记不要用
SET GLOBAL sql_slave_skip_counter = 1跳过，它在 GTID 模式下直接报错
GTID 模式下 position 失效，怎么判断同步卡在哪
开了 GTID 就别看 Exec_Master_Log_Pos，它恒为 4（binlog 文件头固定长度），所有位置信息都由 Executed_Gtid_Set 和 Retrieved_Gtid_Set 表达。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
性能影响：GTID 开启后，每个事务多写 16 字节 UUID + 8 字节事务序号，高并发写入时略有开销，但换来的是故障恢复时无需人工算 position。
- 检查从库是否启用了 GTID：
SELECT @@gtid_mode;返回ON才适用这套逻辑 - 对比
Executed_Gtid_Set（已执行）和Retrieved_Gtid_Set（已拉取但未执行）：如果前者不包含后者中的某个 GTID，说明 SQL 线程卡住了 - 常见坑：主库执行了
RESET MASTER，清空了所有 binlog 和 GTID 集合，但从库仍保留旧的Executed_Gtid_Set，导致无法自动重连
为什么 show master status 的 position 和 binlog 文件大小对不上
binlog 文件大小 ≠ 最大 position 值，因为文件开头有 magic number、format description event 等元数据，且每个 event 自带 header（19 字节），这些都不计入 Position 的递增值。
兼容性影响：MySQL 5.6 和 5.7 的 binlog event header 长度不同，跨版本解析时容易误判位置；8.0 启用 binlog_row_image=MINIMAL 后，update 日志体积缩小，position 增长更“稀疏”。
- 用
mysqlbinlog --verbose查看 event 实际偏移，比ls -l看文件大小可靠得多 - 不要用
tail -c 100 mysql-bin.000012截取末尾来“猜”位置，binlog 不是纯文本流，截断会导致解析失败 - 如果主库开启了
sync_binlog=0，崩溃后最后几 KB 可能丢失，SHOW MASTER STATUS显示的Position会比实际写入磁盘的位置更大
真正麻烦的不是 position 对不上，而是对不上之后不敢动——因为不知道哪个事务改了哪些行。这时候与其硬算位置，不如先确认 GTID 是否开启、binlog 格式是 ROW 还是 STATEMENT、从库 error log 里最后一句报错到底指向哪个 SQL。位置只是坐标，上下文才是关键。
