是，从库执行SELECT会卡住复制线程。原因包括：并行复制参数设置过高导致协调器瓶颈；从库缺失主库已有索引引发全表扫描；read_only未严格生效致应用误写；relay_log_recovery=OFF引发重启后重复回放。
从库执行 SELECT 也会卡住复制线程？先看是否启用了 slave_parallel_workers > 0
MySQL 5.7+ 启用并行复制后，slave_parallel_workers 设置过高（比如设为 16），但实际从库 CPU 核数少、磁盘 I/O 弱，反而导致线程争抢严重，SHOW PROCESSLIST 里大量 Waiting for an event from Coordinator 或 Reading event from the relay log 状态。这不是查询慢，是协调器瓶颈。
- 检查当前值：
SELECT @@slave_parallel_workers; - 临时调低测试：
SET GLOBAL slave_parallel_workers = 4;（建议 ≤ CPU 核数 × 0.8） - 注意：该变量需在
STOP SLAVE后再START SLAVE才完全生效
EXPLAIN 显示 type=ALL 且 rows 极大？说明从库缺失主库已有的索引
主库写入时可能只依赖主键或唯一索引加速，但业务查询（尤其是报表、后台导出类 SELECT）在从库上频繁扫描全表——而这些查询根本没在主库上跑过，DBA 也没同步建索引。结果就是从库 Handler_read_rnd_next 暴涨，innodb_buffer_pool_reads 持续升高。
- 抓取从库慢日志（确保
log_slow_slave_statements = ON） - 对典型慢查执行
EXPLAIN FORMAT=TREE，重点看filtered是否低于 10%、rows是否远超实际返回行数 - 比对主从
SHOW CREATE TABLE输出，确认KEY定义是否一致；特别注意FULLTEXT、SPATIAL索引不支持复制，必须手动补
从库开了 read_only=OFF 还被应用写入？查 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？
从库异常宕机后，若 relay_log_recovery=OFF（默认值），MySQL 会从 relay_log.info 记录的位置继续读 relay log——但该文件可能已损坏或滞后，导致重复应用大量历史事件，CPU 和 I/O 短时飙升，看起来像“查询负载高”，实则是复制回放风暴。
- 检查：
SELECT @@relay_log_recovery;，应为ON - 启用方式：停库，在
my.cnf加relay_log_recovery=ON，重启；不能动态设置 - 启用后，每次启动都会丢弃损坏 relay log，从 master 的
master_log_pos重新拉取，更安全但首次启动略慢
真正麻烦的不是没索引，而是索引建了但没覆盖 WHERE + ORDER BY + LIMIT 组合，或者从库用了 tmp_table_size 过小导致频繁磁盘临时表——这些得结合 SHOW PROFILE 和 performance_schema 深挖，别只盯着慢日志。
