应用层需主动实现读写分离，事务内所有语句必须走主库，动态路由应基于方法入口+ThreadLocal+AOP控制，ShardingSphere和pgpool生效需避开事务、SQL特征及配置陷阱。
MySQL 主从复制配置后，应用层怎么自动路由读写
读写分离不是靠数据库自己完成的，得在应用或中间件里做判断。mysql 本身不区分 select 和 insert 的目标实例，主从同步延迟、事务一致性、连接池复用这些全得你主动兜底。
常见错误是直接把所有 SELECT 发给从库，结果刚插入一条记录马上查不到——因为从库还没同步完。更隐蔽的是，在一个 BEGIN...COMMIT 事务里混用读写，如果读被发到从库，就可能读到旧数据甚至报错。
- 事务内所有语句必须走主库（包括
SELECT），哪怕只是SELECT FOR UPDATE - 显式开启读写分离前，先确认从库
Seconds_Behind_Master是否稳定在 0 或可接受阈值（比如 ≤ 1s） - 避免用
mysql_real_escape_string这类已废弃函数做 SQL 拼接，动态路由依赖准确识别语句类型，SQL 注入会破坏判断逻辑
Spring Boot + MyBatis 多数据源下如何控制 DataSource 切换
不能靠注解硬编码指定“这个 @Mapper 走从库”，那样维护成本高、易出错。真正可控的方式是基于方法签名或上下文动态决定数据源，核心在 AbstractRoutingDataSource 的 determineCurrentLookupKey() 方法。
典型陷阱是把路由逻辑写死在 DAO 层——比如某个 UserMapper.selectById() 固定走从库，但调用方在事务里调它，就会崩。应该让路由决策点尽量靠近入口（如 Controller 或 Service 方法入口），并支持手动覆盖。
- 用
ThreadLocal存当前期望的数据源 key（如"master"或"slave"），determineCurrentLookupKey()从中取值 - 提供
@ReadOnly自定义注解，在 AOP 切面中自动设ThreadLocal值；同时保留DataSourceRouter.set("master")手动强制能力 - 务必重写
afterCompletion()清理ThreadLocal，否则线程复用时会继承上一次的路由选择
ShardingSphere-JDBC 的 readwrite-splitting 配置为什么没生效
配置写对了，但所有流量还是打到主库，大概率是没关掉默认的 load-balance-algorithm 行为，或者事务干扰了路由判断。ShardingSphere 默认只对非事务 SELECT 启用读库，且要求 SQL 必须是纯查询（不能含变量、不能带 FOR UPDATE）。
另一个高频问题是 props.sql-show=true 开着时，日志里看到的 SQL 是经过改写的，容易误判路由是否触发；真实链路得看 netstat -anp | grep :3306 或数据库 SHOW PROCESSLIST。
- 检查
spring.shardingsphere.rules[0].readwrite-splitting.data-sources下的write-data-source-name和read-data-source-names是否拼写正确，YAML 缩进错一格就失效 - 确保
transaction-isolation-level在应用侧没设成TRANSACTION_SERIALIZABLE，这会让 ShardingSphere 放弃读写分离 - 从库连接串里别加
allowMultiQueries=true，ShardingSphere 解析多语句时可能误判为非纯读操作
PostgreSQL 的 pgpool-II 做读写分离时，load_balance_mode = on 却总连主库
不是配置开了就能分流，pgpool 默认只对简单 SELECT 生效，而且要求客户端连接时声明 application_name 不含 pgAdmin、psql 等关键词——否则它认为你在做管理操作，强制走主库。
更麻烦的是，pgpool 的健康检查如果失败，会把从库标记为 down，之后所有请求都 fallback 到主库，但日志里可能只报 health check failed，不提示具体原因。
- 用
psql "host=pgpool port=9999 application_name=myapp"测试，确认show pool_nodes中从库状态是up - 检查
pgpool.conf中black_function_list是否误加了now、current_timestamp等函数名，它们会让 pgpool 认为语句不可缓存/不可下推，从而拒绝路由到从库 - 如果应用用了连接池（如 HikariCP），确保
connectionInitSql没执行SET search_path之类改变会话状态的操作，pgpool 可能因此跳过负载均衡
实际部署时，主从延迟、网络抖动、连接池大小三者互相咬合，光调配置没用。得在业务代码里埋点统计每次查询的实际执行节点，并监控 pg_stat_replication 的 replay_lag，不然所谓“读写分离”只是个幻觉。
