ProxySQL不能自动识别读写操作，必须手动配置mysql_query_rules表规则才能实现语句级路由；默认无规则，所有流量走default_hostgroup。
ProxySQL能自动识别SELECT和写操作并路由吗
能，但必须配置规则，不能开箱即用。ProxySQL默认不解析SQL语义，mysql_query_rules表才是路由逻辑的唯一控制点。
常见错误是只配置了用户默认hostgroup，却没加SQL匹配规则，导致所有请求都走default_hostgroup（比如全发到主库）。
-
^SELECT匹配所有以SELECT开头的语句，但会漏掉带注释的/*+ read_from_slave */ SELECT ... -
^SELECT.*FOR UPDATE必须放在^SELECT之前，否则会被前置规则提前匹配并终止应用 - 规则
apply=1表示匹配后停止后续规则匹配；若需多条件组合，得用flagIN/flagOUT链式跳转 - 执行完INSERT后紧跟SELECT，若未开启
transaction_persistent=1，可能跨库读到旧数据
ShardingSphere-JDBC在Spring Boot里怎么配读写分离
它不依赖代理进程，直接嵌入应用层，适合Java微服务。核心是声明readwrite-splitting规则，并指定负载均衡策略。
容易踩的坑是误以为“自动”等于“无感知”——实际仍需显式配置从库列表、健康检查SQL、权重或算法，且事务内所有SQL默认强制走主库。
- 配置中
write-data-source-name必须对应一个已定义的数据源bean名，拼错会启动失败，报错Cannot resolve write data source -
read-data-source-names支持逗号分隔多个从库，但每个名字也必须在dataSources里正确定义 -
loadBalancerName: random或roundRobin只影响读请求分发，不干预写；若设为weight，还需额外配props: weights - Hint方式强制走主库：
HintManager.getInstance().setWriteRouteOnly();，但必须在同一线程内、事务开始前调用
MySQL Router适合快速验证读写分离吗
适合，尤其当你只想验证主从复制是否生效、又不想碰复杂中间件时。它是MySQL官方轻量工具，无需JVM，单二进制即可运行。
但它不支持动态权重、SQL级路由或查询缓存，仅基于连接协议做简单分发，本质是“读写端口分离”而非“SQL内容识别”。
- 启动命令必须带
--conf-base-dir指定配置目录，否则报错Could not find configuration file - 配置文件中
[routing:read_only]段的destinations必须写成server1:3306,server2:3306格式，不能换行或加空格 - 它不校验从库
read_only=ON状态，若从库被误写入，Router照常转发读请求过去，造成脏数据 - 故障转移仅依赖MySQL Group Replication拓扑发现，对传统主从架构只能手动切换配置
主从延迟大时，读请求怎么避免查到旧数据
没有银弹方案，只有分级应对：业务可接受最终一致性 → 用延迟阈值+自动剔除；强一致性要求 → 改用GTID+semi-sync+Hint强制主库读。
ProxySQL可通过mysql_server_connect脚本定期执行SELECT MASTER_POS_WAIT(...)来探测延迟，但该脚本需自行编写并部署到ProxySQL服务器本地。
- ShardingSphere-JDBC提供
replica-query开关，默认true；设为false则所有读都走主库（牺牲扩展性保一致性） - MySQL 8.0.22+支持
SET SESSION parallel_applier_mode = 'optimistic'加速从库回放，但无法消除延迟本身 - 最易忽略的是应用层缓存：Redis里存了刚写入的数据，却从延迟从库读取，导致缓存与DB不一致
