从库执行SELECT会卡住复制线程？先别急着怪查询，这四个隐藏配置才是真凶

是的，从库执行SELECT会卡住复制线程。原因包括：并行复制参数设置过高导致协调器瓶颈；从库缺失主库已有索引引发全表扫描；read_only未严格生效致应用误写；relay_log_recovery=OFF引发重启后重复回放。

从库执行 SELECT 也会卡住复制线程？先看是否启用了 sla ve_parallel_workers > 0

很多DBA一看到从库复制延迟，第一反应就是主库写入太猛。但有没有想过，问题可能出在你为提升性能而开启的并行复制上？MySQL 5.7之后，sla ve_parallel_workers 这个参数确实是个利器，可一旦设置不当，比如在只有4核的从库上硬生生设成16，效果就适得其反了。线程是开多了，但协调器（Coordinator）根本忙不过来，结果就是SHOW PROCESSLIST里堆满了Waiting for an event from Coordinator或Reading event from the relay log的状态。这哪里是查询慢，分明是内部调度堵车了。

• 先确认现状：跑一下 SELECT @@sla ve_parallel_workers; 看看当前值。
• 如何调整：可以临时设置为 SET GLOBAL sla ve_parallel_workers = 4;（一个经验法则是：不要超过CPU核数的80%）。
• 重要提醒：修改这个变量后，需要先执行 STOP SLA VE，再 START SLA VE，更改才会完全生效。

EXPLAIN 显示 type=ALL 且 rows 极大？说明从库缺失主库已有的索引

主从架构里一个经典的“信息差”陷阱：主库上的写入，可能靠着主键或几个核心唯一索引就能飞快完成。但那些只在从库上跑的查询呢？比如后台的报表分析、大批量数据导出，它们依赖的筛选条件，主库上可能根本用不到。于是，从库就悲剧了——每次查询都变成全表扫描。反映到监控上，就是Handler_read_rnd_next指标飙升，innodb_buffer_pool_reads持续高位，磁盘I/O压力山大。

• 第一步，打开从库的慢查询日志：确保log_slow_sla ve_statements = ON，把那些拖后腿的查询抓出来。
• 第二步，深入分析：对抓到的典型慢查询，用 EXPLAIN FORMAT=TREE 仔细看看。重点关注filtered列（如果低于10%，筛选效率极低）和rows列（是否远远大于实际返回的行数）。
• 第三步，对比校验：分别在主库和从库执行 SHOW CREATE TABLE，仔细比对表结构定义里的KEY部分是否完全一致。这里要特别敲黑板：FULLTEXT（全文索引）和SPATIAL（空间索引）是不会通过复制同步的，必须手动在从库创建。

从库开了 read_only=ON 还被应用写入？查 information_schema.PROCESSLIST 里的 User 和 Host

有时候，从库压力大的根源，是它“被迫”干起了主库的活儿。你以为设置了read_only=ON就高枕无忧了？如果应用连接用的是root账号，或者拥有SUPER权限的账号，它们完全可以绕过这个只读限制。还有一种更隐蔽的情况：某些ORM框架或中间件，可能会偷偷执行SET SESSION sql_log_bin = 0关闭binlog记录，然后就直接往从库写数据。

• 快速排查：执行这条查询 SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' AND USER NOT IN ('system user', 'replication');
• 关注重点：仔细查看结果里的INFO字段，是否包含INSERT、UPDATE、DELETE等写操作命令，同时确认USER是不是来自运维或开发环境的账号。
• 强力锁死：如果想彻底杜绝非复制写入，可以双管齐下：SET GLOBAL read_only = ON; 加上 SET GLOBAL super_read_only = ON;。后者专门用来防止拥有SUPER权限的用户绕过只读限制。

从库 relay_log_recovery=OFF 导致重启后重放大量旧 relay log？

这个场景颇具迷惑性：从库经历了一次异常宕机，重启之后，CPU和I/O利用率突然飙升，看起来像是查询负载暴涨。但实际原因，可能是复制线程在“炒冷饭”。当relay_log_recovery=OFF（MySQL的默认设置）时，从库重启后会依据relay_log.info文件中记录的位置继续读取relay log进行回放。如果这个文件在宕机时损坏，或者记录的位置已经严重滞后，就会导致大量已经处理过的历史事务被重复应用，瞬间引发回放风暴。

• 检查配置：SELECT @@relay_log_recovery;，生产环境建议将其设置为ON。
• 启用方法：这个参数无法动态修改。需要先停止数据库，然后在my.cnf配置文件中添加relay_log_recovery=ON，最后重启实例。
• 机制解读：启用后，MySQL在启动时会自动丢弃任何可能损坏的relay log，然后根据master_log_pos记录的位置，重新从主库拉取binlog事件。这种方式更安全，虽然首次启动时同步会稍慢一些，但杜绝了数据混乱的风险。

说到底，从库的性能问题往往是一系列因素叠加的结果。真正棘手的，可能不是没建索引，而是索引建得不对路，覆盖不了WHERE、ORDER BY、LIMIT的组合查询；也可能是tmp_table_size设置过小，导致复杂的排序、分组操作频繁使用磁盘临时表。排查时，别只盯着慢查询日志，结合SHOW PROFILE和performance_schema进行深度剖析，才能看到问题的全貌。