MySQL集群网络延迟大，核心问题往往不在数据库本身，而在于网络架构、节点部署和SQL协同设计。优化不能只盯着参数调优，得从“数据怎么走”“请求怎么发”“结果怎么回”三个层面系统梳理。
检查集群拓扑与物理部署
延迟高，第一反应不是改配置，而是看节点在哪跑：
确认所有MySQL节点（主、从、Proxy、中间件）是否部署在同一机房、同一可用区；跨机房（尤其跨城、跨云）的RT通常在10ms以上，对强同步集群（如MGR、Galera）是致命瓶颈 检查网卡类型和带宽：虚拟机是否共享千兆网卡？物理服务器是否启用巨帧（Jumbo Frame）？建议至少万兆内网互联，并关闭TCP延迟确认（tcp_delack_timer=0） 用mtr或tcpping实测节点间双向延迟和丢包率，特别关注主从复制链路（比如主→中继→从）的逐跳延迟精简跨节点数据交互路径
很多延迟来自“不该走网络的地方硬走了网络”：
避免应用直连多个MySQL节点做分片路由——引入轻量级代理（如ProxySQL、MySQL Router），让路由逻辑下沉，减少客户端反复建连和DNS解析开销 读写分离场景下，禁止将事务性读（如SELECT ... FOR UPDATE）发到从库；这类请求必须走主库，否则会因主从延迟导致业务逻辑错乱，反而触发重试放大延迟 批量操作尽量合并：把100次单行INSERT换成1次INSERT INTO ... VALUES (...), (...), ...，减少网络往返次数（Round-Trip）调整复制与一致性协议参数
集群内部同步机制往往是隐性延迟源：
MGR集群：调低group_replication_flow_control_mode=DISABLED（仅测试环境），或增大group_replication_flow_control_certifier_threshold缓解流控；生产建议用MEMBER_WEIGHT控制多数派节点优先级，避免边缘节点拖慢整体提交 异步/半同步复制：确认rpl_semi_sync_master_timeout=10000防止单点故障卡死 关闭不必要的复制过滤规则（如SHOW PROCESSLIST里大量Sending to client或Waiting for semi-sync ACK状态，说明网络或从库响应慢 用pt-query-digest分析慢日志，重点关注Network usage字段高的SQL——它们可能返回了几万行、几百MB结果集，本质是应用设计问题 开启Performance Schema，查events_waits_summary_by_host_by_event_name中wait/io/socket类等待是否异常高，直接指向网络层阻塞不复杂但容易忽略：一次延迟优化，70%靠部署收敛，20%靠路径剪枝，剩下10%才是SQL和参数。先画出你的集群流量图，再动手调。
