Oracle读写分离必须继承AbstractRoutingDataSource自定义路由，因dynamic-datasource的@DS注解静态绑定易致事务跨库异常；路由决策须在JDBC连接获取前通过ThreadLocal+正确AOP时机（事务开启前）完成，且需应对Oracle Data Guard延迟导致的“写后读”失败问题。
Oracle读写分离必须用AbstractRoutingDataSource，不能只靠配置
Spring Boot原生不支持Oracle主从自动识别，dynamic-datasource-spring-boot-starter虽能管理多个Oracle数据源，但它的@DS注解是静态绑定的——你得在每个Mapper方法上手动标@DS("master")或@DS("slave1")。这对Oracle场景很危险：一旦事务里混入读操作，就可能跨库导致XA异常或连接泄漏。
真正可行的路径是继承AbstractRoutingDataSource，自己控制路由逻辑。关键点在于：路由决策必须发生在JDBC连接获取前，且要和当前线程/事务生命周期对齐。
- 必须用
ThreadLocal持有当前期望的数据源key（如"master"或"slave_1"），不能依赖方法签名或SQL类型解析 - Oracle没有
SELECT自动走从库的机制，MyBatis拦截器对SELECT语句的识别在Oracle中容易误判（比如SELECT ... FOR UPDATE本质是写） - 事务方法内第一次获取连接时就决定了整个事务的数据源，后续所有DAO调用都复用该连接——这点和MySQL不同，Oracle更严格
RoutingDataSourceHolder的setDataSource调用时机决定成败
很多团队把RoutingDataSourceHolder.setDataSource("slave_1")放在Service层开头，结果发现事务里部分读还是走到主库。原因很简单：Spring的DataSourceTransactionManager在开启事务时就已调用determineTargetDataSource()，此时ThreadLocal还没设值。
正确做法只有两种：
- 用AOP在
@Transactional方法进入前、事务上下文创建前完成设置（切点必须是TransactionAspectSupport.invokeWithinTransaction之前） - 在Controller层显式调用
RoutingDataSourceHolder.setDataSource(...)，且确保该Controller方法本身不带@Transactional - 绝对不要在DAO或Mapper里做
setDataSource——连接已建立，再设无效
Oracle多从库负载均衡只能靠随机策略，别信“权重”
Oracle官方不提供类似MySQL的LOAD_BALANCE连接参数，dynamic-datasource的RandomDynamicDataSourceStrategy是目前最稳的选择。它的实现就一行：dsNames.get(ThreadLocalRandom.current().nextInt(dsNames.size()))。
但要注意：
- 如果你配置了
slave_1、slave_2、slave_3三个从库，随机策略不会考虑各库的CPU/IO负载，纯粹按索引取模——这意味着监控和告警必须覆盖每个从库实例 - Oracle RAC环境里，
slave_x应指向不同SCAN IP，而非同一集群的VIP，否则负载均衡失效 -
strict: false必须设为false，否则某个从库宕机时整个读请求会直接抛NoAvailableDataSourceException
事务内“写后立即读”在Oracle里大概率失败
这是Oracle读写分离最隐蔽的坑。MySQL主从有半同步+GTID可保障秒级延迟，而Oracle Data Guard默认最大性能模式下，从库延迟可能达数秒甚至分钟。你在@Transactional里先INSERT再SELECT，如果路由到从库，查不到刚写的记录是常态。
解决方案不是调低延迟，而是绕开问题：
- 强制事务内所有操作走主库：用
@DS("master")标注整个Service方法，放弃该事务内的读负载分担 - 拆分事务：写操作单独事务提交后，再启新事务做读——但需处理业务一致性（如用Saga模式）
- 查主库兜底：在从库查询无结果时，自动fallback到主库重查一次（注意避免循环调用）
真实生产环境中，90%的“写后读”需求其实源于前端页面跳转后的详情加载，这类场景更适合用缓存（Redis）替代从库直查——毕竟Oracle从库的定位是扛住报表类长查询，不是应付高频点查。
