最简可用DatabaseRouter需实现db_for_read、db_for_write、allow_relation、allow_migrate四个方法，均返回字符串或None；db_for_read按模型返回'slave'或None，db_for_write统一返'default'，allow_relation跨库必返False，allow_migrate仅对default库白名单app返True；注册需在DATABASE_ROUTERS列表中添加类路径字符串，并确保DATABASES含'default'及从库配置。
怎么写一个能用的 DatabaseRouter 类
Django 4 的多数据库路由核心就是实现四个方法：db_for_read、db_for_write、allow_relation、allow_migrate。缺任何一个，Django 都会报 AttributeError。最简可用版本必须返回字符串（数据库别名）或 None，不能返回空字符串或数字。
常见错误是只实现了读写路由，却忘了 allow_migrate——这会导致 python manage.py migrate 报错 ValueError: Database "xxx" does not exist，因为迁移默认只作用于 default，而你的 router 拦截了但没明确放行。
-
db_for_read：建议按模型类判断，比如对User、Order等读多写少的模型返回'slave'；对后台管理类模型可直接返回None（走 default） -
db_for_write：一般统一返回'default'，除非你真有分库写入逻辑 -
allow_relation：跨库外键在 Django 4 中不被支持，所以只要涉及不同数据库的两个 model 实例，必须返回False；同库或含default的组合才可考虑返回True -
allow_migrate：迁移应只发生在default（主库），所以当db == 'default'且app_label在白名单内时返回True；其余一律False或None
settings.py 里怎么注册 router 并配好数据库
必须把 router 类路径加到 DATABASE_ROUTERS，否则 Django 完全不会调用它。这个配置是列表，不是字符串，写成 'myapp.routers.MyRouter' 这种字符串即可，不要带括号或实例化。
数据库配置本身要提前定义好，且每个库的 NAME、HOST、USER 等字段不能遗漏。Django 4 不再容忍 HOST 为空字符串，本地 MySQL 必须显式写 'localhost' 或 '127.0.0.1'（二者行为不同，后者绕过 socket）。
立即学习“Python免费学习笔记（深入）”；
- 主库建议命名为
'default'，这是 Django 内部硬编码依赖的别名，改了会导致 admin、auth、session 等模块异常 - 从库别名如
'slave'或'replica1'，需确保settings.DATABASES字典里真实存在该 key - 如果用了
django-environ，注意环境变量解析后仍要保证每个库的ENGINE值正确，比如'django.db.backends.mysql'不能拼错
怎么验证读操作真的走从库了
光看代码没用，得实测。最直接的方法是在 db_for_read 里加 print(f"READ from {model.__name__} → {db}")，然后执行一个 MyModel.objects.all().first()，观察输出。但生产环境不能打日志，所以更可靠的是查数据库连接数或慢查询日志。
另一个常见陷阱：Django 的 QuerySet 是惰性的，.filter() 不触发查询，只有 .first()、.list()、for obj in qs: 才真正发 SQL。如果你只写了 qs = MyModel.objects.using('slave').all()，那其实是手动指定库，和 router 无关，属于绕过机制。
- 确认是否走 router：删掉
using()调用，只用普通 ORM 查询，再看日志或数据库监控 - 事务内所有读默认强制走写库（即
default），哪怕你在transaction.atomic()里调.all()——这是 Django 的安全策略，无法通过 router 改变 - 使用
django-debug-toolbar时，SQL 面板显示的数据库名才是最终依据，比代码推断更可信
为什么 select_related 和 prefetch_related 会出问题
这两个 API 在多库下极易翻车。select_related 生成 JOIN，而跨库 JOIN 在 MySQL/PostgreSQL 中不合法，Django 会静默降级为多次查询，但可能把本该走从库的关联表查到了主库上；prefetch_related 默认也走主库，除非你显式传 using='slave'，但它不接受 router 动态决策。
根本原因是：Django 的关联查询路由逻辑不经过你的 DatabaseRouter，而是由 QuerySet._db 决定，而这个值在 select_related 构建时就被固化了。所以不要指望 router 能自动分流关联查询。
- 避免在读场景中用
select_related关联主库模型（如User.profile），改用两次独立查询 + 手动组装 -
prefetch_related若必须用，先.using('slave')，再链式调用，例如Book.objects.using('slave').prefetch_related('author') - 自定义 manager 的
get_queryset()中加.using('slave')是可行的，但要注意它无法改变已存在的select_related行为
读写分离不是开个开关就完事的事，router 只管顶层查询入口，关联、事务、缓存、测试 fixture 都可能绕过它。越靠近数据层，越得盯着每一条 SQL 实际发给了谁。
