根本瓶颈是SQL线程单线程回放机制：主库并发写入，从库只能顺序执行relay log，任一事务耗时长即导致后续全部排队；MySQL 5.6+支持库级并行，8.0+推荐WRITESET事务级并行。
主从延迟不是偶发异常，而是MySQL复制模型在高并发写入下的必然表现——核心卡点在从库SQL线程单线程回放机制。
SQL线程单线程回放是根本瓶颈
主库可并发执行数百个DML事务，但从库默认只用一个SQL Thread顺序重放relay log。哪怕主库1秒内提交100个事务，从库也得挨个执行完——中间任何一个事务耗时长（比如UPDATE百万行），后续所有事务都排队等待。
常见错误现象：
-
Seconds_Behind_Master持续增长，但Slave_IO_Running和Slave_SQL_Running都是Yes - 从库
SHOW PROCESSLIST里看到SQL Thread长期处于Updating或Waiting for table metadata lock
关键参数差异：
- MySQL 5.6+ 支持
slave_parallel_type=DATABASE，按库并行，但要求业务写入天然分库 - MySQL 8.0+ 推荐
slave_parallel_type=LOGICAL_CLOCK+binlog_transaction_dependency_tracking=WRITESET，事务级并行，无需业务改造
大事务和DDL会直接阻塞整个复制流
一个未拆分的DELETE FROM logs WHERE create_time 在主库可能执行2分钟，在从库就得卡住2分钟——期间所有后续binlog事件全积压在relay log里，无法推进。
DDL更危险：ALTER TABLE在主库执行完才写入binlog，从库SQL线程遇到它必须先获取MDL锁、执行、再释放，期间所有依赖该表的事务全部挂起。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
使用场景判断：
- 监控
SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos长时间不动，而Read_Master_Log_Pos持续增长 → 典型大事务/DDL卡住SQL线程 - 从库执行
SELECT * FROM information_schema.INNODB_TRX发现长事务持有锁 → 需结合业务日志定位源头
硬件与网络层的隐性拖累常被忽略
从库磁盘慢、CPU弱、网络抖动，不会立刻报错，但会持续放大延迟。例如SATA SSD随机写IOPS仅约100，而NVMe SSD可达5万+；跨机房同步时RTT从0.1ms升至10ms，I/O Thread每拉一条event都要多等10ms，积少成多。
性能影响点：
-
innodb_flush_log_at_trx_commit=1+sync_binlog=1在从库开启会极大拖慢SQL线程落盘速度 - 从库
innodb_buffer_pool_size过小，导致大量索引页需从磁盘读取，放大单事务执行时间 - 主从不在同一VPC或未启用
slave_compressed_protocol=ON，大事务binlog传输耗时翻倍
真正难处理的是组合型延迟：比如主库TPS飙升时恰好触发一个大DDL，同时从库磁盘IO被打满——这种情况下，只调slave_parallel_workers没用，必须同步压测IO、拆分DDL、限制主库大事务入口。不要依赖单一指标Seconds_Behind_Master，它在网络断开时会显示NULL，而真实延迟可能已达数小时。
