Yii 2.0.51 需手动启用 readWriteSplitting=true 并显式配置 slaves 数组；只读查询（如 queryAll、ActiveRecord::find()->one()）走从库，INSERT/UPDATE/DELETE、事务内所有操作及未标记只读的 createCommand() 均走主库；从库宕机不自动降级，需 try/catch 手动 fallback；无延迟检测与重试机制。
Yii 2.0.51 怎么配读写分离（readWriteSplitting）
Yii 2.0.51 默认不开启读写分离，必须手动配置 readWriteSplitting 为 true，且需显式定义 slaves 数组 —— 即使只有一台从库，也不能省略。
-
master和slaves必须是完整数据库连接配置（含dsn、username、password），不能复用同一份配置对象 - 从库宕机时，Yii 不会自动降级或跳过，而是抛出
yii\db\Exception；需自行捕获并 fallback 到主库（比如重试前加try/catch） -
readWriteSplitting只影响SELECT，所有INSERT/UPDATE/DELETE/REPLACE和事务内查询一律走master，哪怕你在事务里写了createCommand()->queryAll()
为什么 createCommand()->queryOne() 还是连主库？
常见错因：没触发 Yii 的读操作识别逻辑。它只对明确标记为“只读”的方法生效，比如 ActiveRecord::find()->one() 或 Command::queryAll()；但 createCommand() 返回的是裸 Command 实例，不带上下文语义。
- 正确写法是：
Yii::$app->db->createCommand($sql)->queryAll()（注意是Yii::$app->db而非new \yii\db\Command） - 如果手写 SQL，且确定是只读，可强制指定：
Yii::$app->db->slave->createCommand($sql)->queryOne() - 使用
ActiveRecord时，find()->asArray()->one()才走从库；findOne()或带joinWith的关联查询可能因隐含锁或事务上下文切回主库
Transaction 内怎么避免误走从库？
事务一旦开启（$transaction = Yii::$app->db->beginTransaction()），后续所有查询——包括 SELECT —— 都强制走主库，这是 Yii 的硬性设计，无法绕过。
- 想在事务中查旧数据做比对？只能提前在事务外用
Yii::$app->db->slave查好缓存到变量里 - 不要试图在事务里调
Yii::$app->db->slave->createCommand(...)->queryOne()，它会被忽略，实际仍走主库 - 嵌套事务或未提交就查数据，容易因主从延迟导致“刚写完就查不到”，这不是配置问题，是架构约束
从库延迟导致数据不一致，能自动重试吗？
不能。Yii 2.0.51 没有内置延迟检测或重试机制。所谓“读写分离”只是路由策略，不包含一致性保障。
- 高敏感场景（如支付结果页），建议关键
SELECT显式走主库：Yii::$app->db->master->createCommand(...)->queryOne() - 若依赖从库，需接受秒级延迟；可用
sleep(0.1)+ 重查（不推荐）或引入 GTID/位点校验（需 MySQL 5.7+ 且应用层配合） -
slaves数组里多个从库是轮询分发，不按负载或延迟排序，也不支持权重配置；要实现智能路由得自己封装Connection子类
读写分离不是开个开关就万事大吉的事，主从延迟、事务边界、查询意图识别、故障转移——每个环节都得在代码里留一手。
