MySQL读写分离通过将读请求分发到从库、写请求发送到主库，能够有效降低主库压力，提升数据库集群的整体处理能力。当读写分离未按预期生效时，需要从多个维度逐步排查问题根源。
一、检查主从复制状态
主从复制异常是导致读写分离失败的常见原因之一，如果主从同步中断，从库数据落后或者无法提供服务，中间件可能会自动将请求切回主库，或者返回错误。可以通过以下步骤检查主从状态：
1. 在主库查看二进制日志状态
登录主库MySQL执行如下命令，确认二进制日志是否正常开启和写入：
-- 查看主库二进制日志状态 SHOW MASTER STATUS;
正常结果会显示当前正在写入的二进制日志文件名和位置，如果返回空结果，说明主库未开启二进制日志，需要检查主库配置文件中的log_bin参数是否开启。
2. 在从库查看复制运行状态
登录从库MySQL执行以下命令，检查复制线程是否正常运行：
-- 查看从库复制状态 SHOW SLAVE STATUSG
重点查看两个字段：Slave_IO_Running和Slave_SQL_Running，这两个值都需要为Yes。如果Slave_IO_Running为No，说明从库无法连接主库获取二进制日志，需要检查主从网络连通性、主库复制账号权限；如果Slave_SQL_Running为No，说明从库执行中继日志时出现错误，需要查看Last_SQL_Error字段定位具体错误原因。
同时需要关注Seconds_Behind_Master字段，该值表示从库落后主库的秒数，如果数值过大，部分读写分离中间件会认为从库不可用，从而将读请求路由到主库。
二、检查路由配置
路由配置错误会直接导致请求无法按规则分发到对应数据库节点，需要根据使用的读写分离实现方式逐一排查。
1. 应用层硬编码路由排查
如果是在应用代码中直接配置主从库地址，手动控制读写请求路由，需要检查代码中的路由逻辑是否正确：
// 示例：Java应用硬编码读写分离路由
public class DBRoute {
private static final String MASTER_URL = "jdbc:mysql://192.168.0.1:3306/test";
private static final String SLAVE_URL = "jdbc:mysql://192.168.0.2:3306/test";
public static String getDBUrl(boolean isWrite) {
// 检查这里的判断逻辑是否正确，是否存在写请求误判为读请求的情况
if (isWrite) {
return MASTER_URL;
} else {
return SLAVE_URL;
}
}
}
需要确认判断读写请求的逻辑是否准确，比如是否存在将更新、插入等写操作错误标记为读操作，导致请求被路由到从库的情况。
2. 中间件路由规则排查
如果使用MyCat、ShardingSphere等中间件实现读写分离，需要检查中间件的路由配置：
以ShardingSphere为例，检查读写分离配置中的主从数据源映射是否正确，是否存在从库节点配置错误、权重设置异常的问题：
# ShardingSphere读写分离配置示例
spring:
shardingsphere:
datasource:
names: master,slave0
master:
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://192.168.0.1:3306/test
username: root
password: test123
slave0:
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://192.168.0.2:3306/test
username: root
password: test123
rules:
readwrite-splitting:
data-sources:
readwrite_ds:
type: Static
props:
write-data-source-name: master
read-data-source-names: slave0
# 检查负载均衡算法配置是否正确
load-balancer-name: round_robin
load-balancers:
round_robin:
type: ROUND_ROBIN
需要确认write-data-source-name和read-data-source-names是否对应正确的数据源，是否存在从库地址配置错误、主库被错误加入读数据源列表的情况。
三、其他常见排查方向
- 检查从库是否正常提供服务：直接连接从库执行简单查询，确认从库本身可以正常响应请求，排除从库宕机、端口不通等问题。
- 检查事务中的请求路由：部分读写分离规则会将事务中的所有请求都路由到主库，避免事务内读写不一致，需要确认业务中的读请求是否在事务内执行。
- 检查中间件的健康检查配置：确认中间件对从库的健康检查规则是否合理，是否存在健康检查误判从库不可用，从而将读请求全部切到主库的情况。
四、排查流程总结
可以按照以下顺序逐步排查：先检查从库复制状态是否正常，再检查路由配置是否正确，最后排查应用层、中间件的其他相关规则。定位到问题后，针对性修复即可恢复读写分离功能。