MySQL 读写分离主从延迟严重时，优先通过数据库参数优化减少延迟根源，中间件层面推荐选用支持延迟感知路由的 ShardingSphere 或 ProxySQL，强制关键业务读主库是保证一致性的兜底方案。
先说结论：中间件无法消除物理延迟，只能感知并路由，核心策略是“能等则等，不能等读主”。
- 适合：业务容忍秒级延迟且读多写少的场景，使用支持延迟阈值的中间件自动切换。
- 重点看：中间件是否支持基于 Seconds_Behind_Master 的动态路由策略。
- 别忽略：金融级一致性业务必须绕过中间件强制读主库，不可依赖从库。
命令速用版
登录从库执行以下命令，确认延迟数值是否超过业务容忍阈值：
SHOW SLAVE STATUS\G
关注 Seconds_Behind_Master 字段，若为 NULL 表示复制线程未运行，若数值持续大于 0 则存在延迟。
为什么会这样
主从延迟本质是主库 binlog 生成速度超过从库回放速度，或网络传输耗时过高。
MySQL 传统复制是单线程回放，当主库并发写入高或存在大事务时，从库排队执行导致延迟累积。中间件的作用不是加速复制，而是在延迟过高时将读请求路由回主库，避免读到旧数据。
分步处理
第一步：确认延迟来源
检查从库 Seconds_Behind_Master。若延迟稳定且数值小，可能是网络抖动；若持续增大，检查是否有大事务或未优化 SQL。
第二步：数据库层优化
MySQL 5.7 及以上版本开启多线程复制（MTS），设置 slave_parallel_workers 大于 0。公开资料中没有看到可靠的量化数据表明具体提升比例，但官方文档确认该参数可提升回放并发度。
第三步：中间件配置延迟阈值
以 ShardingSphere 为例，配置读写分离策略时设置 slave-lag-threshold。当从库延迟超过该毫秒数，中间件自动将请求路由至主库。
第四步：业务层兜底
对于支付、余额等强一致性场景，代码层面添加路由_hint_，强制指定数据源为主库，不经过读写分离逻辑。
怎么验证是否生效
在业务高峰期观察中间件日志或监控面板，确认当从库延迟升高时，读请求流量是否自动切换至主库。
再次执行 SHOW SLAVE STATUS\G，确认延迟数值是否在阈值波动范围内。若配置了强制读主，验证关键业务数据读取是否实时一致。
常见坑
1. 中间件自身成为瓶颈：引入 ProxySQL 或 ShardingSphere-Proxy 会增加网络跳数，需评估中间件性能损耗。
2. 主库压力雪崩：若从库普遍延迟过高，所有流量压向主库，可能导致主库宕机。需设置最大主库连接数保护。
3. 复制线程假死：有时 Seconds_Behind_Master 显示正常但实际未同步，需结合 Last_IO_Error 和 Last_SQL_Error 综合判断。
常见问题
中间件能彻底消除主从延迟吗？
不能。中间件只能感知延迟并切换路由，无法改变 MySQL 复制机制本身的物理耗时。
什么场景必须强制读主库？
涉及资金变动、用户状态更新后立即读取的场景，必须强制读主库以保证数据一致性。
ShardingSphere 和 ProxySQL 怎么选？
Java 技术栈优先选 ShardingSphere-JDBC 无代理模式，多语言混合架构选 ProxySQL 或 ShardingSphere-Proxy。
参考来源
- MySQL Official Documentation, Replication, https://dev.mysql.com/doc/refman/8.0/en/replication.html
- Apache ShardingSphere, Readwrite-Splitting, https://shardingsphere.apache.org/document/current/cn/features/readwrite-splitting/