MySQL读写分离中间件选型应按场景区分：Java微服务优先ShardingSphere-JDBC，多语言架构选ProxySQL，避免用MyCat做简单读写分离；ProxySQL规则需按顺序精确配置，启用match_digest、及时加载保存规则，并结合延迟监控与业务Hint保障一致性。
MySQL读写分离中间件选型：ShardingSphere-JDBC vs MyCat vs ProxySQL
选错中间件，后面所有路由逻辑都得返工。ShardingSphere-JDBC 是 JVM 进程内轻量路由，适合 Java 应用直连，但无法跨语言；MyCat 是独立代理，兼容 MySQL 协议，但配置复杂、DDL 支持弱；ProxySQL 最稳，SQL 解析精准、支持读写权重和故障自动摘除，但不内置分库分表逻辑。
常见错误现象：SELECT 被发到主库、INSERT 后立刻 SELECT 查不到（从库延迟）、SHOW PROCESSLIST 里看到大量连接卡在 Waiting for table metadata lock（MyCat 的全局锁问题）。
- Java 微服务优先用
shardingsphere-jdbc，通过readwrite-splitting配置 +hint强制走主库 - PHP/Python 多语言混合架构选
ProxySQL，用mysql_query_rules匹配SELECT并路由到hostgroup 10（从库组） - 避免用 MyCat 做高并发简单读写分离——它的
schema.xml中<dataNode>和<dataHost>嵌套容易配错，导致所有流量打到同一节点
ProxySQL 自动路由规则怎么写才不翻车
规则顺序决定路由结果，不是“匹配任意一条”，而是“第一条完全匹配即生效”。很多人把 SELECT 规则放最后，结果被前面的 UPDATE 或通配规则吞掉。
使用场景：需要让 SELECT COUNT(*) FROM orders 走主库（避免从库延迟导致统计不准），但其他 SELECT 走从库。
- 必须开启
mysql_query_rules.active = 1，否则规则不生效 - 规则字段优先用
match_digest（正则匹配归一化后的 SQL），比match_pattern更可靠，例如：^SELECT.*COUNT\(\*\).+orders$ - 给关键一致性查询加
apply = 1并设destination_hostgroup = 20（主库组），同时设置sticky_conn = 1防止事务中路由跳变 - 别忘了执行
LOAD MYSQL QUERY RULES TO RUNTIME和SAVE MYSQL QUERY RULES TO DISK，否则重启就丢
从库延迟大时，强制读主库的三种触发方式
单纯靠 HINT 或中间件规则不够，因为应用层无法感知从库延迟值。必须结合监控指标做动态决策。
性能影响：每次查 Seconds_Behind_Master 会多一次 SHOW SLAVE STATUS 查询，ProxySQL 可缓存 1 秒，ShardingSphere 需自己加 replica-query-delay-threshold-ms 参数。
- 在 ProxySQL 中用
mysql_servers表的max_replication_lag字段限制单个从库最大延迟，超阈值自动下线 - ShardingSphere-JDBC 设置
props: { sql-show: true }仅用于调试，上线必须关——它会让每条 SQL 多打一次日志，QPS 下降 15%+ - 业务层最稳妥的方式：对订单详情、支付状态等强一致场景，在 DAO 层显式调用
HintManager.getInstance().setWriteRouteOnly()，而不是依赖 SQL 解析
为什么 autocommit=0 的事务里读写分离会失效
几乎所有中间件都依赖 autocommit 状态判断是否处于事务中。一旦 SET autocommit = 0，后续所有语句（包括 SELECT）都会被路由到主库——这是正确行为，不是 bug。
容易踩的坑：Spring @Transactional(isolation = ISOLATION_READ_COMMITTED) 默认不改 autocommit，但若手动执行了 SET autocommit = 0，会导致整个事务期间无法利用从库读取能力。
- 检查 JDBC URL 是否含
?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true——这些参数本身不影响路由，但若漏掉rewriteBatchedStatements=true，批量插入性能会差 3 倍以上 - MyBatis 中
<select>标签默认走从库，但若该方法被@Transactional包裹且事务传播为REQUIRED，就会退化为主库 - ProxySQL 不识别 JDBC 的事务标记，只认 MySQL 协议层面的
BEGIN/START TRANSACTION，所以 Spring 的TransactionSynchronizationManager对它无效
真正难处理的是跨服务调用下的读写分离一致性——比如 A 服务写完发 MQ，B 服务消费后查从库，这时延迟不可控。这种场景没法靠中间件解决，得靠业务层加重试或最终一致性补偿。
