maxscale不支持真正的动态负载均衡，其readwritesplit仅按静态权重或轮询分发读请求，动态性仅体现在基于延迟和健康状态的节点剔除。
MaxScale 本身不自动感知从库实时负载（如 CPU、QPS、延迟），所谓“动态负载均衡”实际依赖健康检查 + 静态路由策略组合实现，不是按 CPU 或连接数实时调度。
MaxScale 的 readwritesplit 路由不支持真正的动态权重调整
很多人误以为 readwritesplit 能像 Nginx 那样根据后端响应时间自动切流。实际上，它只做两件事：把 SELECT 发到从库组，把写操作发到主库。从库之间的流量分配是静态的——默认轮询（roundrobin），也可配固定权重（weight），但这个权重在运行时无法自动变化。
- 配置中设置
weight=10和weight=5是启动时读取的，改了要 reload 配置或重启服务 - 没有内置插件能实时采集
SHOW GLOBAL STATUS或performance_schema数据来重算权重 - 所谓“动态”，仅体现在故障转移层面：当监控发现某从库
slave_io_running=No或复制延迟 >replication_lag_threshold，它会临时剔除该节点
真正影响读请求分发的关键参数是 monitor 和 service 配置
负载是否“高效”，取决于你是否让 MaxScale 准确识别哪些从库当前可读、可承受流量。这靠两个模块协同：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
[MariaDB-Monitor]必须启用detect_stale_master=true和detect_replication_lag=true，并设合理replication_lag_threshold（单位毫秒，建议设为 500–2000） -
[Read-Write-Service]的router_options中必须包含max_slave_replication_lag=2000，否则即使 monitor 报告延迟超标，router 仍可能转发请求过去 - 从库账号需有
SELECT权限且能访问information_schema.replication_applier_status_by_coordinator（MySQL 8.0+）或show slave status（5.7）
避免 SELECT 被错误路由到主库的常见陷阱
看似简单的读请求，常因语法或上下文被 readwritesplit 强制打到主库，导致从库流量压不上去：
- 带
FOR UPDATE或LOCK IN SHARE MODE的SELECT—— 默认走主库，除非显式加/*+ maxscale */提示 - 在事务中执行的
SELECT（哪怕没写操作），只要事务未提交，后续所有读都走主库 - 使用了用户变量（
@var:=...）、子查询含写操作、或触发器关联表，也可能触发降级 - 客户端连接时未指定
autocommit=1，会导致整个会话处于隐式事务中
高并发下连接池和语句解析开销不可忽视
MaxScale 是单进程多线程模型，每个客户端连接都会消耗内存和 CPU。在 QPS 过万场景下，容易成为瓶颈：
- 默认
max_connections=1000，需根据实际连接数调大，但也要注意系统文件描述符限制（ulimit -n） -
router_options=strict_multi_stmt=false可减少多语句解析压力，但会牺牲部分 SQL 兼容性 - 开启
query_classifier_cache_size=10000能缓存常用语句类型判断结果，降低 CPU 占用 - 不要把 MaxScale 和 MySQL 部署在同一台低配机器上，尤其当从库规格差异大（比如一台 16C、一台 2C）时，代理层资源争抢会放大不均衡
真正决定负载是否“高效”的，从来不是 MaxScale 能不能自动挑最闲的从库，而是你有没有让它的健康检查足够灵敏、路由规则足够干净、以及应用层有没有主动规避那些会让读请求“逃逸”到主库的写法。延迟几毫秒的复制滞后不可怕，可怕的是你配置了三台从库，结果 90% 的读请求因为事务或锁提示全挤在主库上。
