mysql router 不能真正实现读写分离，它仅按配置路由连接而不解析sql；proxysql通过query rules支持语句级读写分离，但需手动配置规则、健康检查和权重，且事务中select需特殊处理避免一致性问题。
MySQL Router 能否真正实现读写分离？
不能直接实现，MySQL Router 本身不解析 SQL、不判断读写意图，它只做连接路由——根据配置把客户端请求转发到后端 MySQL 实例（主库或从库），但「转发到哪」完全取决于你手动写的路由规则，不是自动按 SELECT/INSERT 区分的。
常见误用是以为启用 --conf-use-gr 就能自动读写分离，其实它只是配合 InnoDB Cluster 自动发现节点角色（PRIMARY/SECONDARY），仍需你显式定义两组路由：read-write 和 read-only，并让应用主动连不同端口。
- 必须在配置中明确声明
[routing:rw]和[routing:ro]两个段，分别绑定不同端口和目标模式 - 应用层要自己决定：写操作连
localhost:6446，读操作连localhost:6447—— Router 不会拦截并重定向 SQL - 如果从库延迟高，Router 不感知复制延迟，也不会自动剔除节点（除非配合 Cluster 的故障转移机制）
ProxySQL 配置读写分离的关键三步
ProxySQL 是更贴近需求的方案，它通过 mysql_query_rules 表匹配 SQL 模式，再结合 hostgroup 路由到不同后端，支持真正的语句级读写分离。但默认不开启，必须手动配置规则+健康检查+权重。
典型配置流程：
- 先在
mysql_servers表里注册主库（hostgroup_id = 10）和从库（hostgroup_id = 20），并设weight控制读流量分配 - 向
mysql_query_rules插入规则：匹配^(SELECT|select)的语句路由到20，其余（含INSERT/UPDATE/SET）路由到10；注意apply = 1和sticky_conn = 1可选，但事务场景下建议开启 - 执行
LOAD MYSQL QUERY RULES TO RUNTIME和SAVE MYSQL QUERY RULES TO DISK生效，别漏掉后者，否则重启丢失
容易踩的坑：SELECT 规则若没加 case_sensitive = 0，遇到大写 SELECT /*+ READ_FROM_SLAVE */ 就不匹配；另外 mysql_replication_hostgroups 表仅用于监控复制延迟自动升降权，不替代 query rules。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
应用不改代码时，如何最小侵入接入？
如果无法修改应用连接字符串或 SQL 逻辑，ProxySQL 仍可做到零改动，前提是应用当前直连的是单台 MySQL（比如 192.168.1.10:3306），只需把它替换成 ProxySQL 地址，并在 mysql_servers 中把原地址设为主库，再添加从库地址即可。
但要注意两点：
- 必须关闭
mysql-monitor模块的monitor_enabled = 0（默认开启），否则它会尝试用monitor用户连所有后端，而你的从库可能没配该用户，导致整个 hostgroup 被标记为 OFFLINE - 事务中的
SELECT会被规则误判为读请求，路由到从库造成一致性问题——此时应在mysql_query_rules中增加条件flagIN = 1并配合flagOUT = 1标记事务内语句，再写一条高优先级规则捕获flagIN = 1的 SELECT 并强制走主库
为什么 ProxySQL 的 latency_weighting 不适合生产读负载均衡？
ProxySQL 支持对同一 hostgroup 内多台从库按响应延迟动态调整权重（latency_weighting = 1），但实际效果不稳定：延迟采样基于 PING 或 SELECT 1，和真实查询负载无关；且权重更新有滞后，突发慢查询不会立刻降权，反而可能把新连接继续打过去。
更可靠的做法是关掉 latency_weighting，改用静态 weight + 主动健康检查（mysql-monitor 的 read_only 检查）+ 手动 SET ONLINE/OFFLINE 控制节点进出。复制延迟大的从库，应通过 mysql_replication_hostgroups 的 max_replication_lag 参数自动隔离，而不是依赖延迟加权。
复杂点在于：这些机制彼此不联动，replication_lag 判断和 read_only 状态检查是两套逻辑，得同时配置才真正防脑裂读。
