MySQL主从复制无复制锁，但从库SQL Thread单线程回放易因大事务、DDL等引发MDL锁或行锁阻塞，导致延迟；优化需启用多线程复制、避免从库DDL、控制事务粒度并监控锁等待。
主从复制本身不加锁，但写操作和同步延迟会间接引发锁竞争
说到MySQL主从复制，一个常见的误解是复制过程本身会“加锁”。其实不然，主库写入时并不会为复制专门上锁。真正的瓶颈往往藏在从库那边。从库在回放Relay Log时，默认的SQL Thread是单线程的，它得老老实实地按顺序执行事务。这就好比一条单车道，一旦前面遇到个大货车——比如一个耗时极长的大事务，或者一个需要锁表的DDL操作——后面所有的车（同步任务）就都得堵着。结果就是复制延迟。
这时候，主库本身是畅通无阻的，但应用如果去读从库，拿到的可能就是过时的数据。更要命的是，从库自己在执行ALTER TABLE或者一个全表扫描的UPDATE时，可是会实实在在地持有MDL锁或行锁的，这就会阻塞从库上其他的查询请求。
- 主库的
binlog写入行为，主要受sync_binlog和innodb_flush_log_at_trx_commit这两个参数控制。如果都设为1，意味着每次事务提交都要刷盘，这会增加IO压力，但这跟“复制锁”是两码事。 - 从库SQL Thread的单线程回放模式，才是高并发写入场景下性能瓶颈的根源。它容易导致relay log堆积，直观表现就是
Seconds_Behind_Master > 0。 - 很多同学会给从库设置
read_only=1来防止误写，这没错。但它管不了内部SQL Thread的写操作，也影响不了锁的行为，别指望它能解决延迟问题。
如何确认是不是锁导致从库变慢？看这三处指标
遇到从库延迟，别靠猜，直接动手查。关键不在于“有没有锁”，而在于“锁是否在从库回放阶段成了那个拖后腿的瓶颈”。重点看下面三个地方：
- 执行
SHOW PROCESSLIST命令，重点查找状态为Waiting for table metadata lock（等待元数据锁）或者Updating（正在更新）的线程，特别是那些运行时间超长的。如果Command列显示是Query，那很可能就是SQL Thread正在执行的语句卡住了。 - 查询
information_schema.INNODB_TRX表，看看有没有事务持续时间远超出平均水平的（比如超过60秒）。同时留意事务状态TRX_STATE为‘RUNNING’但TRX_ROWS_LOCKED（锁定的行数）却很高的记录，这通常是锁争用的信号。 - 对比
SHOW SLA VE STATUS\G输出中的Exec_Master_Log_Pos（已执行的日志位置）和Read_Master_Log_Pos（已读取的日志位置）。如果两者的差值在稳定增长，说明I/O线程接收日志是正常的，问题出在SQL线程回放慢；如果两个位置都停滞不前，那可能是主库binlog写入出了问题，或者网络连接中断了。
真正有效的调优动作：绕开锁瓶颈，而不是调锁参数
MySQL的复制层并没有一个所谓的“复制锁开关”让你去调节。因此，优化的核心思路是减少锁争用的机会、加速事务回放、以及拆分压力来源。具体可以这么做：
- 将从库升级到MySQL 5.7或更高版本，并启用多线程复制。设置
sla ve_parallel_type=LOGICAL_CLOCK和sla ve_parallel_workers=4（worker数量可按需调整），可以让从库按事务组并行回放，大幅提升效率。注意，这通常需要主库配合开启binlog_group_commit_sync_delay来生成更多可并行的事务组。 - 严格避免在从库上直接执行耗时的DDL操作。所有表结构变更都应该在主库完成。同时，评估是否可以使用
pt-online-schema-change这类在线改表工具，以显著缩短DDL持有锁的时间。 - 在主库写入端控制事务粒度。单个事务尽量不要更新超过10万行数据。对于批量数据导入，考虑使用
LOAD DATA INFILE并分批次提交，这样可以有效减少binlog事件的大小，减轻从库的回放压力。 - 持续监控从库的
innodb_row_lock_waits（行锁等待次数）和innodb_row_lock_time_a vg（平均行锁等待时间）。如果发现从库的这两项指标明显高于主库，那很可能意味着从库回放的事务正在触发激烈的行锁竞争，常见原因包括使用了没有索引的WHERE条件进行更新。
一个典型陷阱：以为 set global read_only=1 就安全了
这是一个非常普遍的认知误区。read_only=1这个设置，仅仅只是阻止了普通用户账号的写操作。但对于复制线程（在PROCESSLIST中显示为system user）和拥有SUPER权限的管理员账号，它是不起作用的。
更关键的是，这个参数完全无法阻止从库因为回放Relay Log而产生的内部锁，也丝毫不能缓解SQL Thread单线程这个根本的性能瓶颈。很多运维团队在开启read_only后就放松了警惕，结果某天，一个没有合适索引的UPDATE语句在从库上执行了足足两个小时，拖垮了所有依赖该从库的报表查询，事后排查却找不到任何“人为”的写操作痕迹。
所以，真正需要时刻盯住的，从来不是“从库能不能被写入”，而是“事务回放快不快”以及“锁等待久不久”。复制延迟那个数字的背后，往往就是一条正在发生的、长长的锁等待链。
