需显式配置databases字典定义多个数据库，每个有唯一别名和完整engine；编写databaserouter类覆盖四个方法控制路由；迁移须用--database指定目标库；orm操作需显式using()，save/delete不继承上下文。
如何配置Django的DATABASES设置以支持多数据库
Django本身不自动区分读写或业务库，必须显式定义多个数据库连接，并通过DATABASES字典配置。漏掉NAME、ENGINE或拼错HOST会导致OperationalError: database not found或连接超时。
关键点：每个数据库必须有唯一别名（如'default'、'analytics'），且ENGINE值要完整（例如'django.db.backends.postgresql'，不能只写'postgresql'）；SQLite路径需用绝对路径，相对路径在迁移时容易因工作目录变化而失效。
-
'default'数据库必须存在，即使你从不直接用它——Django的auth、contenttypes等内置app默认绑定它 - 非
default数据库若不含TEST配置，运行python manage.py test时可能报KeyError: 'NAME' - PostgreSQL用户密码含特殊字符（如
@、/）时，必须URL编码，否则DatabaseWrapper解析失败
怎么写一个靠谱的DatabaseRouter类
路由类不是“选库”，而是决定「哪个模型走哪个库」和「哪些操作允许跨库」。Django调用db_for_read()、db_for_write()、allow_relation()、allow_migrate()四个方法，任一返回None即视为拒绝，不是“跳过”。
常见错误：在allow_migrate()里只判断app_label却忽略model_name，导致auth.User被误路由到分析库；或在allow_relation()中未显式允许default与analytics之间的外键关联，引发IntegrityError。
- 务必覆盖全部四个方法，哪怕只返回
None或固定值，否则Django会抛AttributeError -
allow_migrate()中db == 'default'和app_label == 'auth'要同时成立才放行，避免迁移脚本把用户表建到错误库 - 如果某模型需要读写分离，
db_for_read()可返回'replica'，但db_for_write()必须返回'primary'，且两者不能相同（否则失去意义）
执行migrate时为什么总提示“No migrations to apply”或“Table doesn’t exist”
根本原因：Django迁移系统默认只对default库操作。不指定--database参数，python manage.py migrate永远只查default里的django_migrations表，其他库的迁移状态完全不感知。
正确做法是每次迁移都明确指定目标库：python manage.py migrate --database=analytics。但注意：同一个迁移文件不能在多个库重复执行，否则django_migrations记录冲突，后续migrate会跳过或报错。
- 首次为新库运行迁移前，先用
python manage.py migrate --database=analytics --plan确认将执行哪些迁移 - 如果某app只属于
analytics库，应在allow_migrate()中返回False给default，否则makemigrations生成的迁移文件仍会被default尝试应用 - 跨库外键字段（如
ForeignKey指向另一库的模型）无法被Django ORM验证，makemigrations不会报错，但运行时查不到数据
QuerySet执行时如何强制指定数据库
ORM默认走default，但.using()不是“建议”，而是硬性路由开关。一旦调用MyModel.objects.using('analytics').all()，所有后续链式操作（.filter()、.select_related()）都锁定该库，连.count()也发往analytics。
容易被忽略的是.save()和.delete()：它们不继承.using()上下文，必须显式传参，否则回退到default——这是数据错位的高发场景。
-
obj = MyModel.objects.using('analytics').get(id=1)→ 读取没问题；但obj.save()会存到default，除非写成obj.save(using='analytics') -
select_related()跨库无效，Django禁止JOIN不同数据库的表，强行使用会抛NotSupportedError - 事务（
transaction.atomic()）无法跨库，using='analytics'的事务只锁该库，default库的操作完全不受影响
多数据库真正的复杂点不在配置，而在于边界意识：Django不会帮你检查“这个查询是否该去那个库”，也不会阻止你在analytics库里创建User实例。所有路由逻辑都靠代码显式声明和人工校验，少一处using或一个allow_migrate条件，就可能让数据静默漂移到错误位置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
