本文详解如何在 django 多数据库（postgresql + clickhouse）架构下，安全、可靠地初始化并应用 clickhouse 的迁移，避免 `django_migrations` 表冲突、重复建表等典型错误。
在 Django 项目中集成 ClickHouse 作为分析型数据库时，常采用双数据库策略：PostgreSQL 承担事务性业务（如用户、权限、会话），ClickHouse 负责高性能聚合查询（如日志、事件流）。但 Django 原生不支持 ClickHouse，需借助第三方后端（如 django-clickhouse-backend）。此时一个关键挑战浮现：如何让 Django 的迁移系统（manage.py migrate）正确识别并管理 ClickHouse 数据库的状态？
问题根源在于迁移生命周期错位。如提问所述，早期直接使用 CREATE TABLE 手动建表，跳过了 Django 迁移流程，导致 django_migrations 表缺失，而后续执行 migrate --database clickhouse --fake-initial 时，Django 尝试自动创建该表（因检测到无迁移记录），却因 ClickHouse 中已存在同名表（如 edl.django_migrations）而报错 Code: 57 — Table already exists——这恰恰说明 Django 在“补全历史”过程中误判了初始状态。
✅ 正确解法不是强行修补迁移文件或反复 fake，而是重建迁移共识：
-
确认 ClickHouse 当前状态
首先检查 ClickHouse 中是否已存在 django_migrations 表（通常位于默认 database，如 edl）：SELECT * FROM system.tables WHERE database = 'edl' AND name = 'django_migrations';
若存在，且其内容为空或不完整，可安全删除：
DROP TABLE IF EXISTS edl.django_migrations;
-
手动注入初始迁移记录（推荐用于生产环境）
既然所有模型表（如 edl.users_user, edl.contenttypes_contenttype）已由原始 SQL 创建完毕，只需告诉 Django “这些迁移已生效”。执行以下命令插入对应记录（以 contenttypes.0001_initial 为例）：python manage.py migrate contenttypes 0001 --database clickhouse --fake python manage.py migrate auth 0001 --database clickhouse --fake python manage.py migrate admin 0001 --database clickhouse --fake # ... 逐个对齐已存在的迁移
⚠️ 注意：--fake 仅写入 django_migrations 表，不执行 DDL。务必确保对应表结构与迁移文件定义完全一致（字段名、类型、引擎、排序键等），否则后续 makemigrations 可能生成错误差异。
-
验证与后续维护
执行 python manage.py showmigrations --database clickhouse 确认所有历史迁移标记为 [X]。此后新增模型变更时：- 运行 python manage.py makemigrations（Django 会基于当前模型与 django_migrations 记录生成新迁移）
- 使用 python manage.py migrate --database clickhouse 应用（ClickHouse 后端将生成兼容的 ALTER TABLE 或 REPLACE PARTITION 语句）
❌ 避免以下高风险操作：
- 直接删除整个 ClickHouse 数据库（虽彻底但不可控，丢失所有历史数据）；
- 混用 --fake-initial 与已存在的表（该参数仅适用于 全新空库 场景）；
- 将 PostgreSQL 的 django_migrations 表导出导入 ClickHouse（结构/类型不兼容，ClickHouse 不支持 id SERIAL PRIMARY KEY 等）。
? 最佳实践建议：
- 为
ClickHouse 单独定义 clickhouse 数据库路由，明确区分读写逻辑；
- 在 settings.py 中配置 CLICKHOUSE_DATABASES 并禁用 django.contrib.* 的 ClickHouse 自动注册（除非真需在 CH 中存 auth 数据）；
- 对 ClickHouse 模型启用 managed = False（若纯作只读宽表），或使用 clickhouse_backend.models.ClickHouseModel 显式声明引擎与分区策略。
迁移不是一次性的任务，而是数据库演进的契约。尊重 Django 迁移系统的语义（--fake = 已存在，--fake-initial = 全新库），才能在多引擎环境中实现可持续的 schema 管理。
