SQL线程通过读取—解析—重放串行执行relay log：按事件粒度拉取、二进制反序列化解析、严格顺序重放DML/DDL，并受位点更新、错误中断、自动清理等机制约束保障一致性。
中继日志（Relay Log）被 SQL 线程执行，本质是“读取—解析—重放”的串行过程：SQL 线程按顺序读取 relay log 中的 binlog 事件，将其转换为具体的数据操作（如 INSERT、UPDATE、DELETE），并在从库本地执行，从而复现主库变更。
SQL 线程如何读取 relay log
SQL 线程持续监控 relay log 的当前写入位置（由 relay-log.info 或 performance_schema.replication_applier_status_by_worker 记录），从已刷盘且标记为“可执行”的最早事件开始读取。它不直接读文件系统，而是通过 MySQL 内部日志接口按事件粒度拉取：
- 每次读取一个完整事件（event），例如 Query_log_event、Write_rows_log_event、Xid_log_event
- 跳过注释、格式描述事件（Format_description_log_event）等元信息
- 识别事务边界（BEGIN / COMMIT / XID），确保事务原子性重放
SQL 线程如何解析和重放事件
解析不是文本解析，而是二进制反序列化。每个事件携带类型标识、时间戳、server_id、数据库名、表名、变更数据（ROW 格式下含前镜像/后镜像）、GTID（若启用）等字段：
- 对于 DML 事件（如 Write_rows_log_event），SQL 线程构造对应行级操作，在目标表上执行 INSERT/UPDATE/DELETE
- 对于 DDL 事件（如 Query_log_event 包含 CREATE TABLE），直接在从库执行该语句（需注意字符集、SQL_MODE 兼容性）
- 遇到 GTID 时，会先检查是否已执行过该 GTID，避免重复应用（幂等保障）
执行过程中的关键控制点
SQL 线程不是无脑执行，它受多个机制约束以保障一致性与可靠性：
- 串行执行：默认单线程模式下，所有事件严格按 relay log 中顺序执行，避免并发导致的数据错乱
- 错误中断：若某条语句执行失败（如主键冲突、缺失表、权限不足），SQL 线程停止并报错（Seconds_Behind_Master 变为 NULL），需人工干预（如 SET GLOBAL sql_slave_skip_counter=1 或注入空事务）
- 位点更新：每成功执行完一个事务，SQL 线程更新其在 relay log 中的读取位置，并同步刷新 relay-log.info 文件（或写入 mysql.slave_relay_log_info 表，取决于 relay_log_info_repository 设置）
- 自动清理：当 relay log 中所有事件均被 SQL 线程执行完毕，且 relay_log_purge = ON（默认），MySQL 会自动删除已过期的 relay-bin.* 文件
如何验证 SQL 线程正在执行 relay log
可通过以下命令实时观察：
- SHOW SLAVE STATUS\G → 查看 Relay_Log_File 和 Relay_Log_Pos 是否推进；Exec_Master_Log_Pos 是否跟随增长；Seconds_Behind_Master 是否稳定下降
- mysqlbinlog /var/lib/mysql/mysql-relay-bin.000002 → 直接查看中继日志内容，确认事件结构与主库 binlog 一致
- SELECT * FROM performance_schema.replication_applier_status_by_worker; → 多线程复制下，可看到各 worker 线程处理的 relay log 位置
