在Django管理命令中导入新数据前如何彻底清空业务表

你现在遇到的3000条查询结果，本质是上一次爬取的1500条旧数据根本没有被真正删除，只是被前端的过滤条件隐藏了而已

• 你现在的判断逻辑存在关键漏洞：Django中queryset.delete()的返回值是元组格式(总删除行数, {关联模型: 删除行数})，非空的元组在Python中永远会被判定为布尔值True。哪怕实际删除的行数是0，你的代码也会打印"Yesterday's data cleared"的日志，完全没法通过这个判断确认删除操作是否真的执行成功。
• 前端只显示1500条数据，大概率是因为查询逻辑加了当日日期的过滤条件，把旧的1500条历史日期的记录屏蔽了，页面看不到不代表数据库里不存在这些冗余。

• 只要是存在于数据库表中的真实行记录，不管前端是否过滤、是否展示，都会实打实占用磁盘存储空间。sqlite环境下，哪怕后续真的删除了这些冗余记录，数据库文件也不会自动缩小释放空间，需要手动执行VACUUM命令才会把空闲空间回收给操作系统。
• 目前3000条记录的存储空间可以忽略，但如果后续达到每日10万级的爬取规模，每次清空不彻底导致的冗余累积，最后会严重拖慢主表的查询性能。

• 首先调整判断逻辑，直接通过实际删除行数判断操作结果，不要依赖delete返回值的布尔属性：

delete_count, delete_detail = model_data.objects.all().delete()
actual_main_table_delete = delete_detail.get('app.model_data', 0)
if actual_main_table_delete > 0:
    print(f"已清理主表{actual_main_table_delete}条旧数据，开始爬取当日数据")
else:
    print("主表无旧数据可清理，直接开始爬取")

• 这套逻辑是完全跨数据库兼容的，后续从sqlite迁到MySQL、PostgreSQL等生产数据库时，不需要修改任何业务代码，仅调整数据库连接配置即可。
• 当后续数据量达到每日10万级时，替换为分批删除逻辑，避免单次删除大表造成的长时锁表问题：

while True:
    # 每次取1000条记录批量删除，控制锁表时长
    batch = model_data.objects.all()[:1000]
    batch_deleted, _ = batch.delete()
    if batch_deleted == 0:
        break

• 注意不要使用数据库原生的TRUNCATE TABLE语句快速清空：这类语句不会触发Django的ORM信号，也不会联动django-simple-history生成对应的历史记录，会直接破坏你现有的历史数据同步机制。

django-simple-history方案的适配性 #

这是当前新手场景下性价比最高的选择：

• 完全无侵入接入：只要给主表挂载HistoricalRecords()字段，所有对主表的增删改操作都会自动在独立的历史表追加版本记录，不需要手写历史同步逻辑。
• 完全匹配核心要求：清空主表的操作只会在历史表追加一条删除版本记录，不会修改、删除历史表中已有的长期价格数据，足够支撑长期价格趋势的展示需求。
• 仅有的缺点是历史表会多存版本追踪字段，单条记录的存储成本比普通业务表高一点，但对于你的数据规模来说可以忽略。

单表存全量+视图层时间过滤方案的优缺点 #

看起来实现简单，实际上完全不匹配你的需求：

• 违背"主表只保留当日最新记录"的设计目标：单表存全量的话，主表记录量会随爬取天数线性增长，按每日10万条计算，一年就会累积3650万条记录，哪怕加了日期索引，查询当日数据的性能也会持续下降。
• 需要自己实现所有的历史保留、日期过滤逻辑，还要手动保证清空主表时不删除历史数据，对于新手来说维护成本远高于使用成熟的django-simple-history方案。

建议现阶段继续使用django-simple-history的方案，不需要过度设计；只有当后续历史数据量达到千万级以上，再考虑把历史数据拆分到独立的OLAP数据库即可，现在没有替换的必要。

• 调整后的清空逻辑不存在sqlite专属的硬编码，后续迁移到远程生产数据库时可以平滑过渡，不需要重写清空流程。
• 注意sqlite本身的文件锁限制，当数据量达到10万级以上时，不要再用sqlite作为生产存储，避免清空大表时的锁表阻塞问题。
• 不要随意删除django-simple-history生成的历史表数据，否则会中断长期价格趋势的展示链路。

内容的提问来源于stack exchange，提问作者Hektar