mysql主从延迟根本原因是sql线程单线程回放relay log，5.6前强制串行执行；5.7+需配置slave_parallel_workers>0且slave_parallel_type='logical_clock'实现并行，同时要求binlog_format=row及从库索引完备。
从库SQL线程单线程回放是根本瓶颈
MySQL 5.6之前默认只有一条SQL Thread串行回放relay log，而主库可以多线程并发写入。哪怕主库只是4个连接同时UPDATE，从库也得按binlog顺序一条条执行——中间只要一个慢查询或锁等待，后续全部卡住。
常见表现：Seconds_Behind_Master持续上涨，但Read_Master_Log_Pos和Exec_Master_Log_Pos差值不大（说明IO没问题，纯SQL层拖后腿）。
- 确认方式：在从库执行
SHOW PROCESSLIST，看SQL Thread状态是否长期为Updating或Waiting for table metadata lock - MySQL 5.7+ 可启用并行复制：
SET GLOBAL slave_parallel_workers = 4;（建议设为CPU核心数的一半） - MySQL 8.0+ 更推荐用
slave_parallel_type = 'LOGICAL_CLOCK'，按事务提交时间戳分组并行，比按库（DATABASE）更细粒度
ROW格式binlog放大回放负载
当前生产环境普遍用binlog_format = ROW，安全但代价明确：一条UPDATE影响10万行，binlog里就记10万个Write_rows_event，从库得逐行解析、定位、更新——比STATEMENT格式多出数倍I/O和CPU消耗。
尤其当从库缺少对应索引时，每行更新都变成全表扫描，性能断崖式下跌。
- 检查方法：
SHOW VARIABLES LIKE 'binlog_format'; - 对比开销：用
mysqlbinlog --base64-output=DECODE-ROWS -v relay-bin.000001 | head -20看事件密度 - 关键规避点：确保从库表结构与主库一致，且所有WHERE条件字段都有索引；避免在无主键表上做DML
大事务或DDL直接阻塞整个复制流
主库一个耗时30秒的ALTER TABLE或批量DELETE，从库必须等它完全执行完才能推进Exec_Master_Log_Pos。期间所有后续事务排队，Seconds_Behind_Master会跳涨几十秒甚至几分钟。
更隐蔽的是隐式大事务：比如应用没显式BEGIN，但单条SQL更新了超大范围（如UPDATE users SET status=1 WHERE created_at ）。
- 定位手段：
SHOW BINLOG EVENTS IN 'mysql-bin.000001' FROM <position> LIMIT 10;</position>结合时间戳看事件跨度 - 拆分策略：用
WHERE id BETWEEN ? AND ?分批次操作，每次控制在1万行以内 - DDL避坑：避免
ADD COLUMN插在大表中间；优先用pt-online-schema-change类工具
从库承载读流量导致资源争抢
很多团队让从库同时跑报表、BI查询、API读请求，结果SQL Thread和用户查询共用同一套buffer pool、同一块磁盘、同一个CPU核——回放延迟本质是被“抢资源”抢出来的。
典型现象：业务低峰期延迟归零，一到白天查询高峰延迟飙升，SHOW PROCESSLIST里能看到大量Sending data或Copying to tmp table状态。
- 快速验证：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';统计非复制线程数量 - 硬隔离方案：给从库加
read_only = ON，再单独部署只读代理或读写分离中间件分流 - 资源倾斜风险：别把
innodb_buffer_pool_size设得和主库一样大——从库不需要缓存写热点，可适当调低，把内存留给OS cache加速relay log读取
真正卡住复制的往往不是某一个参数，而是多个因素叠加：比如ROW格式 + 无索引更新 + 从库跑着慢查询 + 单线程模式。排查时得一层层剥，先看Seconds_Behind_Master涨不涨，再看是IO卡还是SQL卡，最后才深入到语句级和硬件层。
