报表查询应路由至专用从库而非主库，需绑定ETL与同一从库节点、启用逻辑时钟并确保SQL线程运行，MySQL 8.0.2+从库可执行窗口函数但须避免磁盘临时表卡顿。
主库写入压力大，报表查询拖慢业务怎么办
直接把报表 SQL 扔到主库上跑，轻则慢查询告警频发，重则锁表、连接池打满、订单接口超时。这不是 SQL 写得不够优化的问题，是读写混杂的架构缺陷——报表这类高耗资源、低时效性需求，本就不该和交易逻辑抢同一套数据库连接与缓冲区。
核心解法：用从库承接报表查询，但不是简单配个 read_only=1 就完事。ETL 任务和计算下推必须和从库节点深度绑定，否则会出现数据延迟不可控、JOIN 结果错乱、窗口函数偏移等隐性故障。
- 报表 SQL 必须显式路由到指定从库 IP 或连接池（不能依赖中间件自动读写分离，中间件对复杂查询的路由不可信）
- ETL 任务的源端必须指向同一个从库节点（而非“任意从库”），避免因主从复制位点不一致导致增量抽取漏数或重复
- 从库开启
slave_parallel_type=LOGICAL_CLOCK+slave_parallel_workers=4，降低复制延迟，尤其当主库有批量 UPDATE 时
MySQL 从库能直接跑 GROUP BY + 窗口函数吗
能，但前提是版本 ≥ 8.0.2 且从库未开启 skip_slave_start 或处于 SQL_THREAD STOPPED 状态。很多线上从库为了“保稳”，习惯性关掉 SQL 线程手动拉取 binlog，这种模式下 SELECT 看到的是过期快照，窗口函数的 OVER (ORDER BY ...) 会基于陈旧排序生成错误累计值。
更隐蔽的坑是临时表：从库默认 tmp_table_size 和 max_heap_table_size 与主库一致，但报表常触发磁盘临时表，而从库 I/O 能力通常弱于主库，容易卡在 Creating sort index 状态。
- 确认从库 SQL 线程运行中：
SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes且Seconds_Behind_Master - 报表查询前加
SELECT SLEEP(0.1)不解决问题，要改的是复制拓扑和监控阈值 - 对含
RANK()、LAG()的语句，在从库执行前先EXPLAIN FORMAT=TREE，检查是否走索引排序；没走就加覆盖索引，别指望从库有更多内存扛排序
ETL 从库节点选错，增量同步直接丢数据
典型场景：业务用 binlog position 做增量抽取，但 ETL 脚本连的是 A 从库，而监控显示延迟的是 B 从库，误以为整体延迟小就开跑。结果 A 从库因网络抖动落后了 3 分钟，ETL 拿到的 position 对应主库 3 分钟前的状态，新插入的订单记录就此消失。
根本原因在于 MySQL 主从复制是单线程回放（即使开了并行），不同从库的位点进度彼此独立。ETL 必须绑定唯一可追踪的从库，并以该节点的 Exec_Master_Log_Pos 为准推进位点。
- 禁止在 ETL 配置里写
host: mysql-slave这类 DNS 轮询地址，必须硬编码真实 IP - 每次抽取前，先查该从库的
SHOW MASTER STATUS（注意不是SHOW SLAVE STATUS），拿到当前已执行的 binlog 文件和位置 - 如果用 Flink CDC 或 Debezium，确保
database.server.name配置和实际连接的从库物理节点完全一致，否则心跳检测会误判位点
计算下推到从库后，JOIN 主库维表失败
报表需要关联用户画像表（在主库）、订单事实表（在从库），直接 SELECT ... FROM slave_db.orders o JOIN master_db.users u ON o.uid = u.id 会报错 ERROR 1146 (42S02): Table 'master_db.users' doesn't exist —— 因为从库没有该库，也没权限跨实例查询。
这不是权限问题，是 MySQL 架构限制：单条 SQL 无法跨实例 JOIN。所谓“计算下推”，是指把能下推的聚合、过滤、排序尽量留在从库完成，维表数据得提前同步或用应用层拼接。
- 维表变更不频繁（如地区、品类）：用
mysqldump --single-transaction定时全量同步到从库同名库，报表 SQL 改成JOIN slave_db.users - 维表实时性要求高（如用户标签）：ETL 任务在从库建
FEDERATED表（MySQL 5.7+ 默认禁用，需启动时加--federated），但生产环境慎用，FEDERATED 查询会阻塞主库连接 - 最稳方案：应用层分两步查，先从从库取订单 ID 列表，再用
WHERE id IN (...)批量查主库用户信息，控制 IN 列表长度 ≤ 1000 避免长事务
真正难的不是语法怎么写，是判断哪些计算能下推、哪些必须上提——关键看数据新鲜度容忍度和主从延迟毛刺分布。线上从库延迟 P99 达到 8 秒，那就别指望实时用户行为报表能准。
