MySQL集群读写异常应优先排查主从同步状态、连接路由逻辑、权限与配置一致性三类问题：先检查SHOW SLAVE STATUS中IO/SQL线程运行状态及延迟，再验证中间件路由策略与应用SQL分发是否正确，最后比对各节点server_id、binlog_format、字符集、权限及GTID配置一致性。
MySQL集群读写异常，优先排查主从同步状态、连接路由逻辑、权限与配置一致性这三类核心问题，而不是直接怀疑硬件或网络。
检查主从复制是否中断或延迟
集群常见读写异常源于从库延迟过大或复制中断，导致应用读到旧数据或写入被拒绝：
- 登录各节点执行 SHOW SLAVE STATUS\G，重点看 Slave_IO_Running 和 Slave_SQL_Running 是否均为 Yes，Seconds_Behind_Master 是否持续增长
- 若 IO 线程停止，检查主库 binlog 是否开启（show variables like 'log_bin'）、主库授权用户是否具备 REPLICATION SLAVE 权限、网络连通性及端口（默认3306）是否可达
- 若 SQL 线程停止，查看 Seconds_Behind_Master 为 NULL 且 SQL_Delay 非零，或出现 Last_SQL_Error，常见于主从表结构不一致、重复键冲突、误删中继日志等
确认读写分离中间件或客户端路由策略
使用 ProxySQL、MaxScale 或应用层分库分表时，读写异常往往来自错误的流量分发：
- 检查中间件配置中 write_hostgroup 和 read_hostgroup 是否指向正确节点；主库宕机后是否触发自动故障转移并刷新路由缓存
- 在应用侧抓包或开启 MySQL general_log，确认 SELECT 语句是否真的发到了从库，UPDATE/INSERT 是否固定打到主库；避免在事务中混用读写操作导致路由错乱
- 注意 autocommit=0 下的显式事务：即使只执行 SELECT，只要在 BEGIN 后，部分中间件仍会将其路由至主库，造成从库读不到最新结果
核对各节点配置与权限一致性
集群节点间参数不一致极易引发隐性异常，例如主库可写但从库拒绝写入、字符集不匹配导致插入失败：
- 对比关键参数：server_id（必须唯一）、binlog_format（建议 ROW）、lower_case_table_names、collation_server 和 character_set_server
- 检查账号权限：主库创建的用户需在从库上存在且权限匹配，尤其涉及 DEFINER 的视图、存储过程；跨库操作时注意 GRANT ON *.* 是否遗漏
- 验证 GTID 模式一致性（如启用）：gtid_mode=ON、enforce_gtid_consistency=ON 必须在所有节点统一开启，否则 CHANGE MASTER TO 会失败
观察系统资源与日志线索
底层资源瓶颈或错误日志常被忽略，却是定位根因的关键入口：
- 查看 error log（默认 datadir 下的 hostname.err），搜索 “ERROR”、“Aborted”、“Lost connection”、“Deadlock found” 等关键词
- 检查磁盘空间（df -h）和 inode 使用率（df -i）：从库中继日志写满、主库 binlog 归档失败均会导致复制卡住
- 运行 SHOW PROCESSLIST 观察长事务、锁等待（State = "Sending data" / "Waiting for table metadata lock"）；结合 information_schema.INNODB_TRX 分析阻塞源头
不复杂但容易忽略。
