从库报表查询阻塞SQL线程需隔离资源：5.7用max_execution_time、taskset绑CPU、ProxySQL限并发；8.0+用RESOURCE GROUP；根本解法是迁至专用只读实例。
从库查询阻塞SQL线程怎么办
从库上跑报表查询（尤其是大表 SELECT、GROUP BY、ORDER BY）时，如果没加限制，会抢占CPU、内存和磁盘I/O，直接拖慢甚至卡死 SQL thread 的重放速度——表现为 Seconds_Behind_Master 持续上涨，复制延迟飙升。
根本原因不是“查询太慢”，而是MySQL默认不区分任务优先级：SQL thread 和用户查询共用同一套资源调度，且 SQL thread 没有抢占式调度能力。
- 确认是否真被阻塞：执行
SHOW PROCESSLIST，看是否有长时间运行的Query状态连接，同时SHOW SLAVE STATUS\G中Seconds_Behind_Master在增长 - 临时缓解：对报表查询显式加
LOW_PRIORITY（仅对MyISAM有效）或改用SELECT SLEEP(0.1)间隔分批查，但治标不治本 - 真正有效的做法是隔离资源边界——靠
resource group或thread pool控制，但MySQL 8.0+才原生支持RESOURCE GROUP；5.7及更早版本只能靠OS层或查询路由层干预
MySQL 5.7 从库如何限制报表查询资源
5.7没有 RESOURCE GROUP，也不能动态给某个连接分配CPU配额，但可通过组合手段把报表查询“关进笼子”：
- 用
max_execution_time强制超时：在报表连接里先执行SET SESSION max_execution_time = 30000（单位毫秒），避免单条查询跑太久 - 限制并发数：在应用层或代理层（如ProxySQL）控制发往从库的报表连接数，比如只允许最多3个并发查询
- 绑定到低优先级CPU：Linux下用
taskset -c 2,3 mysql -h slave_host启动报表连接，把查询绑到非主业务CPU核上（需确认SQL thread运行在哪几个核） - 禁用查询缓存（
query_cache_type = 0）：避免大查询把缓存池刷空，间接影响SQL thread的元数据访问速度
MySQL 8.0+ 用 RESOURCE GROUP 隔离报表查询
8.0引入的 RESOURCE GROUP 是目前最干净的方案，能直接限制CPU时间和并发线程数，且对 SQL thread 完全无感。
- 创建低优先级组：
CREATE RESOURCE GROUP report_group TYPE=USER VCPU=(2,3) THREAD_PRIORITY=-10; - 把报表连接绑定过去：
ALTER USER 'report_user'@'%' RESOURCE GROUP report_group;（需提前创建该用户） - 生效后，该用户所有查询都受限于指定VCPU和优先级，
SQL thread仍在默认组（USR_default）里自由运行 - 注意：必须用
mysqld启动参数--resource-group开启功能，且不能与thread_pool插件共存
为什么不要在从库直接跑报表
技术上可行，但运维风险极高：一旦报表查询触发OOM Killer、磁盘满或锁表，整个复制链路就断了。更隐蔽的问题是——
-
SQL thread执行DDL（如ALTER TABLE）时会自动获取metadata lock，而报表查询若正在扫描同一张表，就会互相等待，形成死锁式延迟 - 从库的
innodb_buffer_pool_size如果被报表查询占满，SQL thread读取中继日志后解析表结构时频繁换页，性能断崖下跌 - 监控指标（如
Threads_running）失真：你看到的是“当前活跃连接数”，但无法区分是报表还是复制内部线程
真正健壮的做法，是把报表查询迁移到专用只读实例（从从库再拉一层复制），或者用 mysqldump + LOAD DATA INFILE 做离线快照——从库只干一件事：同步。
