读写分离落地前，监控指标必须提前定好，核心盯住延迟、流量分布、连接状态和一致性，其中延迟和流量分布是判断系统是否“真健康”的最关键红线。很多团队在改造前不做监控规划，上线后主库负载下来了，但业务却出现偶发数据不一致，排查半天才发现是监控缺失导致问题定位困难，提前定好监控指标，不是让运维多干活,而是给后续排查留退路。
为什么监控指标必须在读写分离落地前定义
读写分离不是简单的“加一台从库”就结束，数据库角色从单机变成主从拓扑后，系统架构的核心矛盾从“容量瓶颈”变成了“一致性和延迟风险”。
行业共识认为，读写分离最危险的阶段不是流量高峰，而是流量刚切过去的过渡期，这个阶段出现的数据不一致、连接池打满、延迟骤增，如果监控指标没有提前定义，告警阈值没有提前预设，问题就会像暗礁一样,等撞上才发现已经漏水了。
提前定义监控指标的核心原因有三点：
- 主从延迟属于渐进式风险，不会瞬间爆发，没有基线数值做参照，很难判断多少毫秒的延迟属于“需要介入”的级别
- 流量分布决定了资源投放方式，只有监控到位，才能知道读流量是否均匀散到多个从库，还是在压垮某一个节点
- 连接状态是隐性故障源头，读写分离中间件层一旦出现连接泄漏，表现往往是业务偶发超时，不明显但杀伤力大
业内专家指出，监控指标的制定要在“改造前完成”，而不是“上线后补齐”。
读写分离监控哪些指标：四类核心指标逐项拆解
围绕读写分离落地前监控指标清单，可以拆成四个组，每一组对应一类架构风险,缺一组都不算完整的观测体系。
延迟类：读写分离延迟监控怎么做
延迟是读写分离的核心指标，定义为从库回放主库binlog的时间差，这个指标最直观,但最容易被误读。
延迟监控不能只看“当前值”，要看“趋势和抖动频率”，比如同样都是延迟50ms，一个是一整天都在50ms上下波动，一个是每秒从0跳到100ms再回来,后者对业务的影响显然更危险。
监控时需要关注的细项：
- 主库binlog写入位置与从库SQL线程执行位置之间的差距，常见命令
SHOW SLAVE STATUS中的Seconds_Behind_Master字段仅是参考值，特殊情况（如从库无操作、binlog长时间未更新）下会显示为0，要配合Master_Log_File和Read_Master_Log_Pos字段一同判断 - 延迟的持续时间、小时级分布规律，用于判断是业务高峰触发的自然延迟还是从库性能问题导致的异常延迟
- 延迟尖刺的频次，可结合
pt-heartbeat每分钟刷新一次心跳表，高精度检测延迟抖动
延迟的对象是从库，如果读写分离后有一主两从，就要分别监控两个从库的延迟情况,而不能只建一个组提交通道。
流量分布类：读写分离核心指标中数量占比如何观测
读流量占比决定分离效果，有多少流量走了从库、多少还留在主库,这个数据能直接验证改造是否达标。
监控维度包含：
- 主库的QPS和TPS变化曲线，对比改造前后差异
- 从库各自的QPS、当前线程数，判断负载是否均衡
- 读写分离中间件层统计的读请求转发比例，以及各从库实际承接的请求数量是否存在显著差异
实操中，如果使用的是ProxySQL，通过stats_mysql_connection_pool表可以很清楚地看到每个从库的活跃连接数、查询总数分布，如果是应用层路由，则需要在DAO层埋点统计读方法调用量和目标数据源,以判断流量权重设置是否生效。
配置完成后要留意一个现象：读写分离很难做到完全的读流量拆分，排查问题类报表查询、后台管理类的读操作往往还是会路由到主库，监控流量分布时，要保留一定余量，别看到主库仍有读流量就机械地判定为“分离失败”,先确认是否属于预期内的旁路流量。
连接状态类：读写分离监控配置的基础项
读写分离落地后，应用连接的物理链路从“单条”变成“多条”，连接池的健康状态直接影响业务可用性,连接数监控是读写分离落地前监控指标配置中比较基础但又容易被忽略的一项。
连接状态类监控涵盖以下内容：
- 活跃连接数、空闲连接数、等待连接的线程数（对应连接池的三个核心水位）
- 连接池创建、销毁连接的速率，如果出现频繁创建销毁，说明连接池参数未调优或存在连接泄漏
- 中间件与后端MySQL之间的连接健康度，可周期性
SELECT 1校验连接可用性，业务请求的前置探活逻辑也建议在空闲连接借用前做一次，避免拿到已失效的“死连接”
如果团队使用Druid连接池，监控页可查看ActiveCount、PoolingCount、WaitThreadCount等字段；使用HikariCP则需通过自带Actuator端点获取指标，不管使用哪种组件，建议将在等待连接的线程数持续超过MinimumIdle2作为紧急告警条件，因为这说明线程在排队,业务SQL已经在等待资源。
一致性类：读写分离关键指标中的隐性兜底
一致性指标是延迟监控的补充，常见做法是“数据校验巡检”，通过定时任务比对主从库的关键表数据量、checksum值，严格意义上讲，一致性监控不是实时指标,而是周期性的兜底手段。
具体操作路径如下：
- 先校准延迟监控的准确性（确认从库
Seconds_Behind_Master为0） - 再抽取核心业务表做全量数据比对，推荐使用
mysqldiff或pt-table-checksum工具 - 比对发现不一致后再用
pt-table-sync做订正（读分离期间的“数据订正”需格外小心,建议在从库执行后再同步到主库）
一致性监控的重点不在“发现问题”，而在“发现问题后的溯源路径”，如果事前未定义从库延迟与数据一致性之间的关联关系,即使发现不一致也难以判断影响范围。
读写分离延迟监控怎么做：阈值设定与告警分级
确定监控哪些指标之后，下一步工作就是设定阈值，阈值定不好,监控体系等于白搭。
阈值怎么定才能不误报不漏报
阈值设置有两条路线：静态阈值和动态基线。
多数团队起步用静态阈值，比如设定延迟超过3秒就告警，但不同业务的容忍度差异极大，一个普通资讯类应用延迟3秒影响很小,而一个库存扣减场景延迟3秒可能就超卖了。
更建议采用动态基线的设定方式，首先在读写分离落地的“灰度观察期”（前两周）不做任何告警，只做数据记录；然后根据这两周数据确定延迟的正常波动范围（如P95值为200ms，P99值为500ms）；延迟超P95但低于P99时给“预警通知”，超过P99时触发“处理告警”。
告警分级与响应流程
告警分级设置的规则建议按以下模型落地：
- P0级：从库宕机或延迟持续超过5分钟且无恢复趋势，属于P0级故障，需要DBA立即介入，同步暂停从库流量分配
- P1级：延迟超过设定阈值但能在1分钟内自动恢复，需要值班人员关注日志变化趋势，同时检查大事务执行情况
- P2级：连接池等待线程数持续超过阈值，或从库QPS分配不均匀，属于性能劣化的早期预警，可在当个值班周期内处理
- P3级：数据一致性校验比对异常，直接开始排查差异原因，并根据对账结果决定是否需要切换主从节点或恢复数据
预防性处理建议：延迟持续上升且伴随磁盘IO使用率超过80%时，优先排查是否存在大量慢查询落在从库，以及临时表空间是否出现膨胀,这两类问题在读写分离场景下最容易被间歇性告警掩盖成偶发故障。
落地前的监控指标走查清单
网关层监控、中间件层监控、数据库层监控三层指标需要准备到位,自检走查清单如下：
- 主从复制链路是否已在监控中，且已配置
Seconds_Behind_Master趋势采集，对于MySQL 8.0以上版本，可对接Performance Schema中的replication_applier_status_by_worker表观测并行复制线程的工作状态 - 读写分离中间件自身的监控是否已接入（如ProxySQL的
stats_mysql_global表、ShardingSphere的指标端点） - 业务侧的关键读接口是否已埋点，能做到慢SQL与数据源的关联追踪
- 告警通知渠道是否已按P0/P1/P2级别配置不同接收人，P0级建议额外配置短信或电话等强提醒渠道
- 从库的数据校验任务是否已配置定时调度，根据实际环境决定采用每天低频抽查核心表或每周全量比对方案
- 监控对象中是否包含主从切换后的场景，有些团队在主库宕机、自动完成主从切换后，延迟监控的告警规则仍然指向旧的主库IP，导致切换后监控完全失效，这是一个容易出现监控“空窗期”的场景
读写分离和分库分表的监控指标有何区别
很多团队做完读写分离后会考虑顺手把分库分表也做了，但两者的监控区别需要在意，读写分离监控的核心是
主从链路实时状态，分库分表监控的核心是数据路由正确性和跨节点一致性。
读写分离场景要求延迟指标具备秒级采样能力，而分库分表场景更关注分布式事务的成功率以及跨库联查的执行计划，如果规划中同时包含两者改造，建议先分阶段落地，先做读写分离跑通监控流程,再做分库分表改造另建一套监控维度。
检查哪些数据能验证监控配置有效
监控配置是否有效，靠人工观察面板判断意义有限,可通过几个可量化的操作直接验证告警链路是否正常：
- 在从库手动执行
STOP SLAVE，等待约5-10秒后确认是否触发延迟告警，验证延迟检测链路和告警通道是否可用，验证后需及时执行START SLAVE恢复复制 - 通过中间件管理端将某个从库标记为
OFFLINE，观察流量监控中该节点的QPS是否实时归零，确认流量监控采集与路由配置联动正常 - 查询
performance_schema下的events_statements_summary_by_digest，对主库和从库的读查询分布做对比确认流量分配统计是否符合预期，判断读流量是否确实进入了从库
操作都在非生产环境执行属理想情况，若条件受限，可选择低峰期在预发环境操作,对业务无影响。
Q&A：读写分离常见监控问题解答
读写分离后主库负载依旧很高怎么办
先通过流量分布监控确认读流量是否真正打到了从库，如果读流量已在从库但主库负载依旧偏高，排查方向有二：一是从库规格与主库差异较大，导致慢查询实际消耗时间上升，应用侧在等待读请求返回时占用了连接资源；二是业务中存在较大比例的事务内读写，由于事务内一致性要求，路由规则默认将事务内的读请求全部发往主库,这一点可以通过数据库侧的全量日志或中间件路由日志进行确认。
从库延迟监控数值为0但业务读到旧数据是什么原因
这是典型的高级延迟场景，部分计时机制基于“从库执行到主库的哪个binlog位点”进行计算，若主库长时间没有写入操作或从库SQL线程处于等待状态，Seconds_Behind_Master会显示为0但实际回放日志的位点已落后，此时需要检查Master_Log_File和Read_Master_Log_Pos字段，或者直接查询心跳表获取精确延迟，可以尝试查询sys.innodb_lock_waits和performance_schema.events_waits_current来观察SQL线程阻塞情况，修复方向是优化从库的SQL线程操作系统资源调度,以及排查是否存在大事务或DDL长时间占用从库执行线程。
读写分离监控告警该设置在什么粒度
按分钟级做数据收集，按秒级做数据展示，告警触发条件建议基于连续多次采样值来判定，比如连续3次采样（每次间隔10秒）延迟都超阈值，才触发告警，可有效规避单次抖动误报，核心链路建议开启独立的告警分组，在业务高峰期或大促准备阶段提前调整告警阈值，把P1级的敏感度适当调高,调整为更早介入。