主从延迟高时应立即将强一致性读切至主库，禁用自动降级，避免数据不一致；禁用高峰期全库导出，启用并行复制；垂直拆分需按读写特征分离表；分库分表须配独立主从对，并用gtid提升切换可靠性。
主从延迟高时，SELECT 读请求还在打从库？
别硬扛，立刻切走。主从延迟超秒级，从库查不到刚写入的数据，业务就容易出错——比如用户注册后立刻查不到自己信息、订单支付成功却显示未支付。这不是网络抖动，是架构水位到了。
实操建议：
- 所有强一致性读（如用户登录态校验、订单状态查询）必须直连主库，用
/*FORCE_MASTER*/注释或中间件路由规则强制打主 - 中间件（如
ShardingSphere、MyCat）配置read-write-splitting策略时，禁用“自动降级到从库”逻辑，延迟超阈值就报错，不静默 fallback - 应用层加简单判断：对关键读操作，先查主库；若主库不可用再考虑降级，而不是默认走从库
mysqldump 或大事务导致从库 SQL 线程卡住？
这类操作会把从库的 SQL_THREAD 堵死，延迟飙升且恢复慢。不是从库性能差，是它被单线程回放拖住了。
实操建议：
- 禁止在业务高峰期执行
mysqldump --single-transaction导出全库，尤其表行数 >500 万时；改用mydumper并加--chunk-size分片导出 - 检查慢日志里有没有长事务：
SHOW PROCESSLIST中State为Reading event from the relay log且Time持续增长，基本就是它卡了 - 从库开启
slave_parallel_workers > 0（MySQL 5.7+），但注意：仅对跨库 DML 有效；同库多表并发需开启slave_parallel_type = LOGICAL_CLOCK
垂直拆分后，哪些表该留在主库？哪些能独立成库？
垂直拆分不是按字母分表，而是按读写特征和一致性要求切。切错反而增加跨库事务和关联查询成本。
实操建议：
- 高频写 + 强一致读的表（如
user_account、order）必须和主业务库在一起，不拆；它们的变更直接影响下游一致性 - 低频写 + 高频读 + 允许短时延迟的表（如
region_dict、product_category）可独立为只读库，用pt-table-sync定期同步，不走主从复制链 - 日志类、统计类宽表（如
user_behavior_log）直接扔到ClickHouse或ES，彻底脱离 MySQL 主从体系
分库分表真能缓解主从延迟？还是只是转移问题？
分库分表本身不降低延迟，它降低的是单实例负载，从而让主从复制更稳定。但如果你把所有分片都还挂在一个主库后面，延迟只会更难监控、更难定位。
实操建议：
- 每个分片组（shard group）配独立主从对，避免“一主多从”变成“一主多从 × N”，否则主库 IO 和 binlog 写压力翻倍
- 用
GTID替代file + position复制，故障切换时能准确定位同步点，避免误跳过事务导致数据不一致 - 监控不能只看
Seconds_Behind_Master，要抓取relay_log_space、SQL_Delay、Retrieved_Gtid_Set和Executed_Gtid_Set的差值
真正难的不是拆，是拆完怎么让每个主从对都可控、可观测、可快速止损。延迟一旦进秒级，就得当线上事故盯，不能靠“等等看”。
