简介这份资源是一篇完整的毕业设计论文文档主题为基于大数据的家电销售分析系统设计与实现面向计算机相关专业的本科毕业生、课程设计者及需要 Django 项目实战参考的开发者。论文围绕家电销售行业的信息化管理需求系统阐述了从前端界面、后端数据库到服务器端逻辑的完整设计思路涵盖系统首页、个人中心、用户管理、冰箱信息管理、系统管理等核心模块并重点讨论了大数据处理技术、Django 框架应用与 Mysql 数据库设计等关键内容。资源包内仅含 1 个 docx 文件约 4.17MB为排版规范的论文正文包含摘要、目录、绪论、系统开发技术及各功能模块设计等章节结构完整、逻辑清晰。目前已有 127 人学习下载适合作为选题参考、论文写作模板或 Django 项目开发的学习范本帮助读者快速理解系统架构与实现路径节省选题与撰写时间。1. 家电销售数据堆在 Excel 里为什么最后都换成了 Django 加大数据这套组合做过家电销售分析的人大概都经历过这个阶段区域经理每月发来几十张 Excel门店 POS 导出的流水按天分文件电商平台的订单又要单独拉一份 CSV。数据量小的时候透视表还能撑住一旦把三五个渠道、两三年、上百个 SKU 合到一起Excel 直接卡死更别提做同比环比、品类下钻和区域热力了。这个标题讲的就是把这套流程从「手工拼表」升级成「Django 做 Web 层、大数据组件做计算层」的销售分析系统。它解决的核心问题有三个一是多源异构数据的统一入库二是大表聚合查询的响应速度三是把分析结果用 ECharts 大屏和后台报表稳定地呈现给业务方。适合谁看正在做大数据毕设选题、需要一套能跑通又能写进论文的系统骨架的在校生以及中小家电企业里被报表需求追着跑、想自己搭一套分析后台的开发和数据岗。Django 在这里不是主角但它是把大数据计算结果变成可交互页面的那层胶水缺了它分析结果只能停在命令行里。2. Django 与大数据组件在家电销售分析系统里的分工与选型2.1 为什么用 Django 的 MTV 模式承接分析结果Django 的 MTVModel-Template-View在这个场景里分工很清晰。Model 负责把清洗后的销售明细、商品维表、区域维表映射成 ORM 模型View 负责接收前端的筛选条件时间范围、品类、区域去查询预聚合好的结果表Template 则渲染页面骨架真正的图表交给 ECharts 在前端异步拉数据。很多人问 Django 之 MTV 模式的 MTV 有什么作用放到这个系统里就是它把「数据怎么存」「请求怎么处理」「页面怎么显示」三件事解耦销售分析的指标口径变了只改 View 里的查询逻辑不用动前端。选 Django 而不是 Flask 或 FastAPI主要看中它自带 Admin、ORM 和迁移工具。家电销售系统里维表多、字段杂用 Django Admin 能快速搭出一个给运营录商品和门店信息的管理端省掉大量 CRUD 开发。常见做法是先用django-admin startproject建工程再python manage.py startapp sales建业务 app把分析相关的模型都放在这个 app 下。2.2 大数据侧选型离线聚合为主别一上来就上实时家电销售的典型查询是「某品类在某区域某季度的销售额和同比」这类需求对实时性要求不高T1 的离线聚合完全够用。所以大数据侧我一般会选 Hive 或 Spark SQL 做明细层的清洗和聚合把结果写回 MySQL 或 ClickHouseDjango 只读聚合后的结果表。这样做的理由是明细数据可能有几千万行让 Django ORM 直接扫明细表做 group by响应时间会从几百毫秒涨到几十秒用户体验直接崩掉。如果数据量在千万级以内其实用 Pandas 加定时任务也能顶一阵但一旦要写进论文、要体现「大数据」的技术含量Hive 建外部表、Spark 做 ETL 这条链路更站得住。选型时注意一点聚合粒度要提前定好按「日期品类区域」建汇总表前端所有筛选都基于这张表避免每次查询都重新算。2.3 数据从 POS 到分析库的完整链路链路可以拆成四段采集、清洗、聚合、服务。采集阶段把 POS 流水、电商订单、门店库存导出成 CSV 或直接走数据库同步清洗阶段用 Spark 去掉退货冲正、补全缺失的品类编码聚合阶段按天和维度汇总服务阶段由 Django 读取汇总表。下面是一段用 PySpark 做日粒度聚合的示例from pyspark.sql import SparkSession from pyspark.sql.functions import col, sum as _sum, to_date spark SparkSession.builder \ .appName(home_appliance_sales_agg) \ .enableHiveSupport() \ .getOrCreate() # 读取明细层字段含 order_time, category, region, amount, qty detail spark.table(ods_sales_detail) # 过滤退货冲正记录amount 为负的是冲正 valid detail.filter(col(amount) 0) agg valid.withColumn(sale_date, to_date(col(order_time))) \ .groupBy(sale_date, category, region) \ .agg(_sum(amount).alias(total_amount), _sum(qty).alias(total_qty)) # 写入汇总表供 Django 查询 agg.write.mode(overwrite).saveAsTable(dws_sales_daily)这段代码的逻辑是先过滤掉冲正记录避免销售额被负数拉低再按日期、品类、区域三个维度做 group by算出销售额和销量。enableHiveSupport()让 Spark 能直接读写 Hive 表mode(overwrite)表示每次全量覆盖汇总表适合 T1 场景。参数上如果明细表分区是按天分的可以在 filter 里加上分区条件减少扫描量。3. Django 侧建模、查询与 ECharts 大屏对接3.1 用 Django ORM 建汇总表模型并做条件查询汇总表结构定好后Django 侧建一个对应的 Model字段和 Hive 汇总表保持一致。注意db_table要显式指定避免 Django 自动加 app 前缀导致表名对不上。from django.db import models class SalesDaily(models.Model): sale_date models.DateField(db_indexTrue) category models.CharField(max_length64, db_indexTrue) region models.CharField(max_length64, db_indexTrue) total_amount models.DecimalField(max_digits14, decimal_places2) total_qty models.IntegerField() class Meta: db_table dws_sales_daily indexes [ models.Index(fields[sale_date, category, region]), ]逻辑说明sale_date、category、region都加了索引因为前端筛选基本都围绕这三个字段。db_table指向 Hive 同步过来的汇总表。参数上max_digits14是为了容纳大额销售额家电客单价高字段别设太小。查询时用 ORM 的filter加values做聚合示例from django.db.models import Sum from sales.models import SalesDaily def query_sales(start, end, categoryNone, regionNone): qs SalesDaily.objects.filter(sale_date__range[start, end]) if category: qs qs.filter(categorycategory) if region: qs qs.filter(regionregion) return qs.values(sale_date).annotate( amountSum(total_amount), qtySum(total_qty) ).order_by(sale_date)这里sale_date__range做时间范围过滤values(sale_date).annotate(...)相当于 SQL 的 group by 加聚合。如果前端要按品类下钻把values里的字段换成category即可。注意别在循环里逐条查询那是 N1 问题的典型来源。3.2 用 StreamingHttpResponse 导出大报表的正确姿势销售分析系统里经常要导出明细报表数据量大时用普通HttpResponse会把整个结果集拼进内存几万行就可能把进程撑爆。Django 的StreamingHttpResponse可以边查边吐配合生成器逐批输出。这里要重点说content_type和content_disposition两个参数很多人导出乱码或文件名不对就是这两个没设对。import csv from django.http import StreamingHttpResponse from sales.models import SalesDaily class Echo: def write(self, value): return value def export_sales(request): def rows(): yield \ufeff # BOM防止 Excel 打开中文乱码 writer csv.writer(Echo()) yield writer.writerow([日期, 品类, 区域, 销售额, 销量]) qs SalesDaily.objects.all().iterator(chunk_size2000) for obj in qs: yield writer.writerow([ obj.sale_date, obj.category, obj.region, obj.total_amount, obj.total_qty ]) response StreamingHttpResponse(rows(), content_typetext/csv) response[Content-Disposition] attachment; filenamesales_export.csv return response逻辑说明rows()是生成器yield一行吐一行内存占用恒定。iterator(chunk_size2000)让 Django 分批从数据库取数避免一次性加载全部记录。content_typetext/csv告诉浏览器这是 CSV 文件Content-Disposition的attachment表示下载而非内联打开filename指定下载文件名。开头那个\ufeff是 UTF-8 BOM不加的话 Excel 打开中文列名会乱码这是导出功能最常见的坑。3.3 ECharts 大屏的数据接口与前后端约定ECharts 大屏的数据接口建议统一返回{code, msg, data}结构前端拿到data后直接喂给图表。下面是一个返回品类销售占比的视图from django.http import JsonResponse from django.db.models import Sum from sales.models import SalesDaily def category_share(request): qs SalesDaily.objects.values(category).annotate( amountSum(total_amount) ).order_by(-amount) data [{name: item[category], value: float(item[amount])} for item in qs] return JsonResponse({code: 0, msg: ok, data: data})逻辑说明values(category).annotate(Sum(...))按品类聚合order_by(-amount)降序排列前端饼图或柱状图直接消费。float()转换是因为 Decimal 不能直接被 JSON 序列化。前后端约定好字段名后大屏的筛选联动就是前端重新请求接口、重新setOption的事。接口方法关键参数返回结构/api/sales/trendGETstart, end, category日期序列 销售额/api/sales/categoryGETstart, end品类 占比/api/sales/regionGETstart, end区域 销售额/api/sales/exportGETstart, endCSV 流4. 部署、性能与常见排错4.1 Windows 环境下 waitress 加 Nginx 的部署要点很多毕设是在 Windows 上开发和演示的Django 自带的runserver不能用于生产。常见做法是用 waitress 做 WSGI 服务器Nginx 做反向代理和静态文件服务。先装依赖pip install waitress waitress-serve --listen0.0.0.0:8000 config.wsgi:application--listen指定监听地址和端口config.wsgi:application指向工程的 WSGI 入口。Nginx 侧配置反向代理到 8000 端口同时把/static/和/media/指向 Django 的静态目录。注意ALLOWED_HOSTS要加上实际访问的域名或 IP否则会返回 400。静态文件要先执行python manage.py collectstatic收集到统一目录Nginx 才能找到。4.2 大表查询慢的三个排查方向查询慢先看执行计划用explain确认有没有走索引。第一个方向是索引缺失sale_date、category、region的联合索引要覆盖高频查询组合。第二个方向是聚合表粒度太细如果汇总表还是按订单行存的等于没聚合要往上再卷一层。第三个方向是 Django 侧没做分页或缓存大屏接口每次全量算可以在视图上加cache_page装饰器把结果缓存几分钟。from django.views.decorators.cache import cache_page cache_page(60 * 5) def category_share(request): ...cache_page(60 * 5)表示缓存 5 分钟适合变化不频繁的汇总数据。参数按业务刷新频率调T1 的数据缓存几小时都没问题。4.3 数据同步与字段口径不一致的坑Hive 汇总表和 Django Model 最容易出问题的地方是字段类型和口径。比如 Hive 里total_amount是doubleDjango 里是DecimalField同步时要做类型转换再比如「销售额」在业务口径里是否含税、是否扣退货两边必须对齐否则大屏数字和财务报表对不上。建议在同步脚本里加一层校验比对源表和目标表的行数和汇总值差异超过阈值就告警。注意退货冲正记录一定要在清洗阶段处理掉不要留到 Django 查询时再过滤否则聚合表的数字本身就是错的。5. 用 Django 执行查询删除对象做数据清理的进阶技巧系统跑一段时间后汇总表里会积累大量过期数据比如三年前的日粒度明细。这时候需要定期清理Django 的查询删除对象能力就派上用场了。最直接的是SalesDaily.objects.filter(sale_date__ltcutoff).delete()但这条语句会先把所有匹配对象加载进内存再逐条删数据量大时非常慢还可能触发外键级联。更稳的做法是分批删除用iterator配合切片from datetime import date from sales.models import SalesDaily cutoff date(2022, 1, 1) while True: ids list( SalesDaily.objects.filter(sale_date__ltcutoff) .values_list(id, flatTrue)[:5000] ) if not ids: break SalesDaily.objects.filter(id__inids).delete()逻辑说明每次只取 5000 个 id删完再取下一批避免长事务锁表。values_list(id, flatTrue)只取主键减少内存占用。参数上批次大小按数据库承载能力调MySQL 一般 5000 到 10000 比较合适。如果表之间有外键关联删除前要确认级联规则必要时先删子表再删主表。另一个技巧是用_raw_delete绕过 ORM 的信号和级联适合确认没有关联数据的场景但风险高不建议在毕设演示环境之外使用。清理任务建议挂到定时任务里比如用django-crontab或 Windows 计划任务每周跑一次配合日志记录删除行数方便回溯。验证清理效果时直接查SalesDaily.objects.filter(sale_date__ltcutoff).count()是否为 0 即可。本文还有配套的精品资源点击获取 家电销售分析系统：Django 与大数据组件整合实战
简介这份资源是一篇完整的毕业设计论文文档主题为基于大数据的家电销售分析系统设计与实现面向计算机相关专业的本科毕业生、课程设计者及需要 Django 项目实战参考的开发者。论文围绕家电销售行业的信息化管理需求系统阐述了从前端界面、后端数据库到服务器端逻辑的完整设计思路涵盖系统首页、个人中心、用户管理、冰箱信息管理、系统管理等核心模块并重点讨论了大数据处理技术、Django 框架应用与 Mysql 数据库设计等关键内容。资源包内仅含 1 个 docx 文件约 4.17MB为排版规范的论文正文包含摘要、目录、绪论、系统开发技术及各功能模块设计等章节结构完整、逻辑清晰。目前已有 127 人学习下载适合作为选题参考、论文写作模板或 Django 项目开发的学习范本帮助读者快速理解系统架构与实现路径节省选题与撰写时间。1. 家电销售数据堆在 Excel 里为什么最后都换成了 Django 加大数据这套组合做过家电销售分析的人大概都经历过这个阶段区域经理每月发来几十张 Excel门店 POS 导出的流水按天分文件电商平台的订单又要单独拉一份 CSV。数据量小的时候透视表还能撑住一旦把三五个渠道、两三年、上百个 SKU 合到一起Excel 直接卡死更别提做同比环比、品类下钻和区域热力了。这个标题讲的就是把这套流程从「手工拼表」升级成「Django 做 Web 层、大数据组件做计算层」的销售分析系统。它解决的核心问题有三个一是多源异构数据的统一入库二是大表聚合查询的响应速度三是把分析结果用 ECharts 大屏和后台报表稳定地呈现给业务方。适合谁看正在做大数据毕设选题、需要一套能跑通又能写进论文的系统骨架的在校生以及中小家电企业里被报表需求追着跑、想自己搭一套分析后台的开发和数据岗。Django 在这里不是主角但它是把大数据计算结果变成可交互页面的那层胶水缺了它分析结果只能停在命令行里。2. Django 与大数据组件在家电销售分析系统里的分工与选型2.1 为什么用 Django 的 MTV 模式承接分析结果Django 的 MTVModel-Template-View在这个场景里分工很清晰。Model 负责把清洗后的销售明细、商品维表、区域维表映射成 ORM 模型View 负责接收前端的筛选条件时间范围、品类、区域去查询预聚合好的结果表Template 则渲染页面骨架真正的图表交给 ECharts 在前端异步拉数据。很多人问 Django 之 MTV 模式的 MTV 有什么作用放到这个系统里就是它把「数据怎么存」「请求怎么处理」「页面怎么显示」三件事解耦销售分析的指标口径变了只改 View 里的查询逻辑不用动前端。选 Django 而不是 Flask 或 FastAPI主要看中它自带 Admin、ORM 和迁移工具。家电销售系统里维表多、字段杂用 Django Admin 能快速搭出一个给运营录商品和门店信息的管理端省掉大量 CRUD 开发。常见做法是先用django-admin startproject建工程再python manage.py startapp sales建业务 app把分析相关的模型都放在这个 app 下。2.2 大数据侧选型离线聚合为主别一上来就上实时家电销售的典型查询是「某品类在某区域某季度的销售额和同比」这类需求对实时性要求不高T1 的离线聚合完全够用。所以大数据侧我一般会选 Hive 或 Spark SQL 做明细层的清洗和聚合把结果写回 MySQL 或 ClickHouseDjango 只读聚合后的结果表。这样做的理由是明细数据可能有几千万行让 Django ORM 直接扫明细表做 group by响应时间会从几百毫秒涨到几十秒用户体验直接崩掉。如果数据量在千万级以内其实用 Pandas 加定时任务也能顶一阵但一旦要写进论文、要体现「大数据」的技术含量Hive 建外部表、Spark 做 ETL 这条链路更站得住。选型时注意一点聚合粒度要提前定好按「日期品类区域」建汇总表前端所有筛选都基于这张表避免每次查询都重新算。2.3 数据从 POS 到分析库的完整链路链路可以拆成四段采集、清洗、聚合、服务。采集阶段把 POS 流水、电商订单、门店库存导出成 CSV 或直接走数据库同步清洗阶段用 Spark 去掉退货冲正、补全缺失的品类编码聚合阶段按天和维度汇总服务阶段由 Django 读取汇总表。下面是一段用 PySpark 做日粒度聚合的示例from pyspark.sql import SparkSession from pyspark.sql.functions import col, sum as _sum, to_date spark SparkSession.builder \ .appName(home_appliance_sales_agg) \ .enableHiveSupport() \ .getOrCreate() # 读取明细层字段含 order_time, category, region, amount, qty detail spark.table(ods_sales_detail) # 过滤退货冲正记录amount 为负的是冲正 valid detail.filter(col(amount) 0) agg valid.withColumn(sale_date, to_date(col(order_time))) \ .groupBy(sale_date, category, region) \ .agg(_sum(amount).alias(total_amount), _sum(qty).alias(total_qty)) # 写入汇总表供 Django 查询 agg.write.mode(overwrite).saveAsTable(dws_sales_daily)这段代码的逻辑是先过滤掉冲正记录避免销售额被负数拉低再按日期、品类、区域三个维度做 group by算出销售额和销量。enableHiveSupport()让 Spark 能直接读写 Hive 表mode(overwrite)表示每次全量覆盖汇总表适合 T1 场景。参数上如果明细表分区是按天分的可以在 filter 里加上分区条件减少扫描量。3. Django 侧建模、查询与 ECharts 大屏对接3.1 用 Django ORM 建汇总表模型并做条件查询汇总表结构定好后Django 侧建一个对应的 Model字段和 Hive 汇总表保持一致。注意db_table要显式指定避免 Django 自动加 app 前缀导致表名对不上。from django.db import models class SalesDaily(models.Model): sale_date models.DateField(db_indexTrue) category models.CharField(max_length64, db_indexTrue) region models.CharField(max_length64, db_indexTrue) total_amount models.DecimalField(max_digits14, decimal_places2) total_qty models.IntegerField() class Meta: db_table dws_sales_daily indexes [ models.Index(fields[sale_date, category, region]), ]逻辑说明sale_date、category、region都加了索引因为前端筛选基本都围绕这三个字段。db_table指向 Hive 同步过来的汇总表。参数上max_digits14是为了容纳大额销售额家电客单价高字段别设太小。查询时用 ORM 的filter加values做聚合示例from django.db.models import Sum from sales.models import SalesDaily def query_sales(start, end, categoryNone, regionNone): qs SalesDaily.objects.filter(sale_date__range[start, end]) if category: qs qs.filter(categorycategory) if region: qs qs.filter(regionregion) return qs.values(sale_date).annotate( amountSum(total_amount), qtySum(total_qty) ).order_by(sale_date)这里sale_date__range做时间范围过滤values(sale_date).annotate(...)相当于 SQL 的 group by 加聚合。如果前端要按品类下钻把values里的字段换成category即可。注意别在循环里逐条查询那是 N1 问题的典型来源。3.2 用 StreamingHttpResponse 导出大报表的正确姿势销售分析系统里经常要导出明细报表数据量大时用普通HttpResponse会把整个结果集拼进内存几万行就可能把进程撑爆。Django 的StreamingHttpResponse可以边查边吐配合生成器逐批输出。这里要重点说content_type和content_disposition两个参数很多人导出乱码或文件名不对就是这两个没设对。import csv from django.http import StreamingHttpResponse from sales.models import SalesDaily class Echo: def write(self, value): return value def export_sales(request): def rows(): yield \ufeff # BOM防止 Excel 打开中文乱码 writer csv.writer(Echo()) yield writer.writerow([日期, 品类, 区域, 销售额, 销量]) qs SalesDaily.objects.all().iterator(chunk_size2000) for obj in qs: yield writer.writerow([ obj.sale_date, obj.category, obj.region, obj.total_amount, obj.total_qty ]) response StreamingHttpResponse(rows(), content_typetext/csv) response[Content-Disposition] attachment; filenamesales_export.csv return response逻辑说明rows()是生成器yield一行吐一行内存占用恒定。iterator(chunk_size2000)让 Django 分批从数据库取数避免一次性加载全部记录。content_typetext/csv告诉浏览器这是 CSV 文件Content-Disposition的attachment表示下载而非内联打开filename指定下载文件名。开头那个\ufeff是 UTF-8 BOM不加的话 Excel 打开中文列名会乱码这是导出功能最常见的坑。3.3 ECharts 大屏的数据接口与前后端约定ECharts 大屏的数据接口建议统一返回{code, msg, data}结构前端拿到data后直接喂给图表。下面是一个返回品类销售占比的视图from django.http import JsonResponse from django.db.models import Sum from sales.models import SalesDaily def category_share(request): qs SalesDaily.objects.values(category).annotate( amountSum(total_amount) ).order_by(-amount) data [{name: item[category], value: float(item[amount])} for item in qs] return JsonResponse({code: 0, msg: ok, data: data})逻辑说明values(category).annotate(Sum(...))按品类聚合order_by(-amount)降序排列前端饼图或柱状图直接消费。float()转换是因为 Decimal 不能直接被 JSON 序列化。前后端约定好字段名后大屏的筛选联动就是前端重新请求接口、重新setOption的事。接口方法关键参数返回结构/api/sales/trendGETstart, end, category日期序列 销售额/api/sales/categoryGETstart, end品类 占比/api/sales/regionGETstart, end区域 销售额/api/sales/exportGETstart, endCSV 流4. 部署、性能与常见排错4.1 Windows 环境下 waitress 加 Nginx 的部署要点很多毕设是在 Windows 上开发和演示的Django 自带的runserver不能用于生产。常见做法是用 waitress 做 WSGI 服务器Nginx 做反向代理和静态文件服务。先装依赖pip install waitress waitress-serve --listen0.0.0.0:8000 config.wsgi:application--listen指定监听地址和端口config.wsgi:application指向工程的 WSGI 入口。Nginx 侧配置反向代理到 8000 端口同时把/static/和/media/指向 Django 的静态目录。注意ALLOWED_HOSTS要加上实际访问的域名或 IP否则会返回 400。静态文件要先执行python manage.py collectstatic收集到统一目录Nginx 才能找到。4.2 大表查询慢的三个排查方向查询慢先看执行计划用explain确认有没有走索引。第一个方向是索引缺失sale_date、category、region的联合索引要覆盖高频查询组合。第二个方向是聚合表粒度太细如果汇总表还是按订单行存的等于没聚合要往上再卷一层。第三个方向是 Django 侧没做分页或缓存大屏接口每次全量算可以在视图上加cache_page装饰器把结果缓存几分钟。from django.views.decorators.cache import cache_page cache_page(60 * 5) def category_share(request): ...cache_page(60 * 5)表示缓存 5 分钟适合变化不频繁的汇总数据。参数按业务刷新频率调T1 的数据缓存几小时都没问题。4.3 数据同步与字段口径不一致的坑Hive 汇总表和 Django Model 最容易出问题的地方是字段类型和口径。比如 Hive 里total_amount是doubleDjango 里是DecimalField同步时要做类型转换再比如「销售额」在业务口径里是否含税、是否扣退货两边必须对齐否则大屏数字和财务报表对不上。建议在同步脚本里加一层校验比对源表和目标表的行数和汇总值差异超过阈值就告警。注意退货冲正记录一定要在清洗阶段处理掉不要留到 Django 查询时再过滤否则聚合表的数字本身就是错的。5. 用 Django 执行查询删除对象做数据清理的进阶技巧系统跑一段时间后汇总表里会积累大量过期数据比如三年前的日粒度明细。这时候需要定期清理Django 的查询删除对象能力就派上用场了。最直接的是SalesDaily.objects.filter(sale_date__ltcutoff).delete()但这条语句会先把所有匹配对象加载进内存再逐条删数据量大时非常慢还可能触发外键级联。更稳的做法是分批删除用iterator配合切片from datetime import date from sales.models import SalesDaily cutoff date(2022, 1, 1) while True: ids list( SalesDaily.objects.filter(sale_date__ltcutoff) .values_list(id, flatTrue)[:5000] ) if not ids: break SalesDaily.objects.filter(id__inids).delete()逻辑说明每次只取 5000 个 id删完再取下一批避免长事务锁表。values_list(id, flatTrue)只取主键减少内存占用。参数上批次大小按数据库承载能力调MySQL 一般 5000 到 10000 比较合适。如果表之间有外键关联删除前要确认级联规则必要时先删子表再删主表。另一个技巧是用_raw_delete绕过 ORM 的信号和级联适合确认没有关联数据的场景但风险高不建议在毕设演示环境之外使用。清理任务建议挂到定时任务里比如用django-crontab或 Windows 计划任务每周跑一次配合日志记录删除行数方便回溯。验证清理效果时直接查SalesDaily.objects.filter(sale_date__ltcutoff).count()是否为 0 即可。本文还有配套的精品资源点击获取