Django怎么应对海量历史数据的冷热分离
冷热分离不是加个路由就能解决的
很多开发者容易陷入一个误区：以为在Django的urls.py里按时间做个路由分发，比如把/archive/2020/指向另一个视图，问题就解决了。这其实只是流量层面的表层分流，完全没有触及数据存储的核心。
真正的冷热分离，其核心目标非常明确：让高频访问的热数据留在主库，享受快速的读写服务；同时，将那些很少被访问的冷数据移出主库。这么做的好处是立竿见影的：能显著减轻主库的索引维护压力，大幅缩减备份所需的时间和存储空间，最关键的是，避免这些“陈年旧账”拖慢查询优化器的决策速度。
真正的冷热分离核心是热数据留主库、冷数据移出主库以降低索引压力、减少备份体积并避免拖慢查询计划器；否则跨分区查询仍会全表扫描。
如果只做路由分离而数据不动，那么像Article.objects.filter(pub_date__year=2018)这样的查询，即便你心里知道它是查冷数据，数据库可不知道。它依然会进行全表扫描，或者触发一些效率低下的索引，面对千万级的历史数据，无论是PostgreSQL还是MySQL，性能瓶颈都会很快出现。
用Django ORM做归档迁移容易踩的三个坑
迁移数据听起来简单，但直接用QuerySet.delete()删除再加bulk_create()批量插入的“蛮力”方法，在生产环境是行不通的。这种方法不保留原记录的自增ID，对外键约束束手无策，更无法保证事务的原子性——万一中途失败，数据就处于一半一半的尴尬状态。
对于生产环境，原子性和一致性是底线。正确的做法需要关注以下几点：
- 使用
django.db.transaction.atomic装饰器或上下文管理器包裹整个迁移批次，确保“迁入”和“删除”要么一起成功，要么一起回滚。同时，单批次操作量建议控制在5000条以内，避免产生长时间运行的事务锁住原表。 - 在开始迁移前，务必暂时禁用相关模型上的
post_sa ve等信号处理器。否则，每插入一条归档记录，都可能意外触发缓存更新、日志写入等无关操作，严重拖慢速度。 - 目标归档表（比如
article_archive）的字段定义，必须与原表完全一致。这里的一致不仅指字段名和类型，还包括db_column（数据库列名）、default（默认值）、null（是否可为空）等属性。否则，bulk_create可能会静默地忽略不匹配的字段，导致数据丢失。
一个关键逻辑的示例代码如下：
with transaction.atomic():
qs = Article.objects.filter(pub_date__lt='2020-01-01').select_related('author')
records = [ArticleArchive.from_article(a) for a in qs.iterator(chunk_size=2000)]
ArticleArchive.objects.bulk_create(records, batch_size=1000)
qs.delete() # 真删除，非软删
定时脚本别依赖Django shell或manage.py runscript
归档任务通常是定时执行的，但执行环境的选择很重要。使用manage.py runscript来跑，一旦脚本因为某种原因卡住或被系统终止，由于缺乏有效的检查点（checkpoint）机制，下次重启时只能从头再来，效率低下且存在风险。至于在Django shell里交互式执行，那就更不可控了。
更专业的做法是编写独立的Python脚本，通过系统的cron服务或APScheduler这类任务调度库来触发。并且，这个脚本需要具备断点续传的能力：
- 每次运行前，先查询一下记录归档日志的表（例如
ArchiveLog.objects.filter(status='done').order_by('-end_time').first()），获取上一次成功归档的截止时间，作为本次任务的起始点。 - 迁移完每一个批次后，立即将本次处理的
min_id和max_id记录到ArchiveLog表中。这样，即使后续批次失败，重启后也可以精准地从断点处继续，而不是重头开始。 - 在脚本的开头，务必设置
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')，确保Django的配置和数据库路由能够被正确加载。
另外，不要把这种长时运行脚本简单地放在management/commands/目录下伪装成一个Django管理命令。Django命令默认没有运行超时保护，缺乏日志自动轮转机制，也没有资源隔离，并不适合处理需要稳定运行数小时的归档任务。
立即学习“Python免费学习笔记（深入）”；
数据库路由配置要区分「读」和「写」两个维度
配置数据库路由时，考虑必须周全。如果仅仅依靠db_for_read方法，试图把所有对历史数据的查询都导向归档从库，那会留下一个漏洞：那些在后台管理界面进行的、针对已归档数据的“热查询”（比如运营人员搜索某篇旧文章），依然会命中主库。
必须配合模型层面的精细控制：
- 首先，在
settings.DATABASES中为归档数据库单独配置一个别名，例如'archive'。 - 然后，定义一个数据库路由类。对于明确的归档模型（如
ArticleArchive），可以强制其所有读写操作都使用'archive'数据库。而对于Article这类混合了热数据和冷数据的模型，则需要在它的管理器（Manager）或查询集（QuerySet）中做动态判断。例如，在自定义的get_queryset方法中加入逻辑：if pub_date < timezone.now() - timedelta(days=730): return using('archive')。 - 这里有一个高级陷阱：Django ORM的
select_related和prefetch_related在进行关联查询时，可能会忽略你精心设置的路由。因此，涉及跨库的关联查询，稳妥的做法是手动拆解。比如，先查ArticleArchive拿到author_id列表，再根据这些ID去主库查询对应的User信息。
说到底，路由配置不是一个非此即彼的开关，而是一种细粒度的“流量染色”机制。如果没有做好“写”的分离（即归档数据仍可能被写入主库），那么归档库就只是一个静态的备份盘；同样，如果没有做好“读”的动态判定，对冷数据的查询请求依然会压垮主库的连接池。
最后，还有一个最常被忽略的细节：外键引用完整性。数据归档后，像Comment.article_id这样的外键，可能仍然指向主库Article表中已经不存在的ID。处理这个问题，通常有两种思路：要么将这类外键字段改为普通的IntegerField，并在业务逻辑层进行校验；要么利用数据库的联邦查询功能（例如PostgreSQL的postgres_fdw扩展）创建跨库视图。对于MySQL而言，实现跨库透明查询比较困难，很多时候不得不妥协为在应用层进行两次独立的查询。
