大事务和DDL操作是主从延迟最典型的“堵点”，因其强制SQL线程串行阻塞，必须等执行完才能处理后续事件；根治需拆分大事务、用gh-ost绕过DDL锁、启用logical_clock+writeset并行复制。
大事务和DDL操作是主从延迟最典型的“堵点”，不是单纯慢，而是让从库SQL线程彻底卡住——它必须等整个事务或ALTER执行完，才能处理后续所有事件。解决的关键在于“拆堵”和“绕堵”，而不是一味加资源。
立即止血：快速识别并临时缓解
发现Seconds_Behind_Master突增至数百秒、Exec_Master_Log_Pos长期不动时，先确认是否被阻塞：
- 在从库执行SHOW PROCESSLIST，重点看SQL Thread状态：若长时间显示"Executing"、"Waiting for table metadata lock"，基本可判定是DDL或大事务阻塞
- 运行SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA NOT IN ('performance_schema','mysql');，查出正在持有MDL锁的会话ID
- 若确认是长查询占着表不让DDL回放，可考虑KILL该慢查询（需评估业务影响）
- 紧急情况下，可临时停掉非核心报表查询，释放IO和CPU资源给SQL Thread
根治大事务：拆分+控制+监控
百万行UPDATE/DELETE不能一气呵成，必须分批提交：
- 用WHERE + LIMIT + ORDER BY主键分页处理，例如：
DELETE FROM t1 WHERE id BETWEEN ? AND ?，每次处理1万行，间隔100ms再执行下一批 - 应用层写循环逻辑，或用存储过程封装，确保每批都COMMIT，避免事务日志过大
- 在业务低峰期执行，并提前在从库SET SESSION innodb_flush_log_at_trx_commit = 2（仅限临时，事后恢复为1）减轻刷盘压力
- 接入审计工具，在上线前拦截未分批的大DML语句，从源头卡控
绕开DDL锁表：用gh-ost替代原生命令
ALTER TABLE直接执行，等于给主从同步埋雷；gh-ost通过影子表+binlog解析实现无锁变更，从库只看到轻量DML和一次RENAME：
- 主库必须开启binlog_row_image = FULL，且用户具备SELECT/INSERT/UPDATE/DELETE/CREATE/DROP权限
- 命令中必须指定唯一排序索引（如主键），否则无法分块迁移：
--chunk-size=1000 --max-load="Threads_running=25" - 典型执行：
./gh-ost --host=主库IP --database=sysbench_db --table=t1 --alter="ADD COLUMN c1 INT" --assume-rbr --allow-on-master --cut-over-exponential-backoff - 全程不锁原表，从库延迟几乎无感知，适合高频更新的核心表
提升从库回放能力：并行复制必须配对生效
开了slave_parallel_workers不代表就真并行了，关键要看事务分组策略是否匹配业务模式：
- MySQL 5.7建议设slave_parallel_type = LOGICAL_CLOCK，但仅对同一库内多表并发有效；跨库事务仍串行
- MySQL 8.0务必启用WRITESET：
SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;+slave_parallel_type = LOGICAL_CLOCK - 验证是否生效：执行SHOW PROCESSLIST应看到多个Worker N线程，且SHOW SLAVE STATUS\G中Slave_SQL_Running_State显示worker正在工作
- 配合innodb_buffer_pool_size调大（建议为主库70%）、使用SSD磁盘，避免IO成为新瓶颈
