应用层读写分离需在代码中显式路由：用abstractroutingdatasource配合threadlocal管理数据源键，service入口调用datasourcecontextholder.setread()声明读操作，异步场景须手动传递上下文，hikaricp双数据源配置+server_id验证确保请求真实分发至从库。
怎么在应用层模拟读写分离的路由行为
MySQL 本身不提供应用层的数据源路由能力，所谓“读写分离测试”，本质是让应用自己决定该走 writeDataSource 还是 readDataSource。不能依赖 MySQL 配置去自动分发 SQL——它连你是 SELECT 还是 INSERT 都不知道。
常见错误是试图在 MySQL 主从架构里配个代理（比如 ProxySQL）就以为完成了“应用层切换”，其实那属于中间件层，和题目要求的“应用层配置数据源切换”完全不是一回事。
- 必须在代码里显式指定数据源：比如 Spring 的
@Transactional(readOnly = true)只是提示，不保证走读库；真正起作用的是AbstractRoutingDataSource的determineCurrentLookupKey()返回值 - 读操作不加任何标记，默认可能仍走写库——很多框架默认数据源就是主库，
readOnly=true不会自动触发切换 - 事务内所有操作强制走同一数据源，哪怕你 mix 了 SELECT 和 UPDATE，也必须由事务发起时的路由规则锁定
Spring Boot + AbstractRoutingDataSource 怎么配才不翻车
这是最贴近题干“应用层配置数据源切换”的标准做法，但极易因线程复用或异步调用失效。
核心陷阱在于：ThreadLocal 存储的 lookup key 在异步线程、定时任务、甚至某些 RPC 调用后会被清空，导致后续 SQL 悄悄 fallback 到默认数据源（通常是主库），你以为在测读库，其实全打到主库上去了。
- 务必重写
AbstractRoutingDataSource.determineCurrentLookupKey()，返回字符串如"read"或"write"，不能返回 null - 在 service 方法入口用
DataSourceContextHolder.setRead()显式声明，别依赖 AOP 自动识别 SQL 类型——AOP 拦不到 MyBatis 的@Select注解方法 - 遇到
@Async或CompletableFuture，必须手动把当前线程的 lookup key 传递过去，否则子线程里ThreadLocal.get()是 null - 单元测试时容易漏掉
DataSourceContextHolder.reset()，导致前一个 test 的路由状态污染下一个 test
为什么用 HikariCP 单独配两个数据源比用 ShardingSphere 更适合测试
ShardingSphere-JDBC 的 master-slave 模式看起来开箱即用，但它会接管 SQL 解析，把简单 SELECT 强制发给从库——这掩盖了应用层路由逻辑的真实缺陷。你要测的是“你的代码是否正确决策”，不是“中间件能不能猜对”。
用两个独立 HikariDataSource（分别连主库和从库），再套一层 AbstractRoutingDataSource，才能暴露真实问题：
- 主库连接串里必须含
failOverReadOnly=false（MySQL JDBC 默认开启 failover，会悄悄把只读请求切到主库） - 从库连接串建议加
readOnly=true，这样即使路由错了，执行INSERT也会立刻报错：Connection is read-only，比静默写入主库更容易发现问题 - 两个 Hikari 连接池的
poolName建议设成"hikari-write"和"hikari-read"，查日志时一眼能确认 SQL 走了哪个池
怎么验证读请求真到了从库而不是主库
光看应用日志不够，MySQL 的 SHOW PROCESSLIST 或 performance_schema 才算数。别信“我打了 @ReadOnly 就一定走从库”这种直觉。
最容易被忽略的一点：MySQL 主从复制有延迟，你在从库查到旧数据，不代表请求发过去了——可能只是你刚巧连上了主库，而主库返回的就是旧数据（比如事务还没提交）。
- 在从库执行
SELECT @@server_id，和你配置的从库server-id对比；主库执行同样语句，结果必须不同 - 在应用侧开启 MyBatis 日志（
logging.level.org.apache.ibatis=DEBUG），找==> Preparing: SELECT ...上方的o.s.j.d.DataSourceUtils - Fetching JDBC Connection from DataSource日志，里面会打印具体数据源 bean 名 - 如果用了连接池监控（如 Hikari 的
/actuator/metrics/hikaricp.connections.active），对比两个池的 active 连接数变化，读请求期间hikari-read的活跃数应明显上升
复杂点永远在上下文传递和事务边界——ThreadLocal 不会跨线程，事务注解不会跨方法调用链，这些地方一松懈，读写分离就变成“看起来分了，其实没分”。
