Django Models实战：从字段定义到生产迁移的完整链路 1. 项目概述这不是在学“模型”是在给数据世界修路“Jumping Into Django Models”——这个标题乍看像一句轻快的口号但如果你刚从Python基础爬出来正对着Django文档发懵或者已经跑通了python manage.py runserver却卡在“怎么把用户信息存进数据库”这一步那这句话背后其实是条实打实的、带坡度的工程路径。它不是教你怎么背诵models.Model的继承关系而是带你亲手把一张Excel表格、一个微信小程序的用户注册表单、甚至是一份仓库出入库记录翻译成Django能听懂、数据库能存下、前端能调用、未来还能快速改的结构化语言。核心关键词就三个Django、Models、Python——它们不是并列关系而是层级依赖Python是地基Django是施工队Models就是这支队伍里负责画蓝图、定钢筋规格、标水电点位的结构工程师。你不需要先成为SQL大师也不必搞懂InnoDB的B树索引原理但必须明白CharField(max_length50)不是随便写的数字on_deletemodels.CASCADE不是复制粘贴的固定后缀related_name更不是可有可无的装饰品。我带过二十多个零基础转行的学员90%的人在第三天崩溃不是因为写不出视图函数而是因为makemigrations报错后死磕django.db.utils.IntegrityError: NOT NULL constraint failed翻遍教程只看到“加nullTrue”却不知道为什么加、加在哪、加了之后历史数据怎么处理。这篇内容就是为那个卡在迁移命令前、盯着终端光标发呆的你写的。它适合所有正在真实项目中落地Django的人自学入门者、小团队后端新手、需要快速补全Django数据层认知的前端转全栈者以及那些被“all models are temporarily rate-limited. please try again in a few minutes.”这类错误提示绕晕、其实根本和限流无关、只是字段定义冲突的开发者。接下来的内容不讲抽象概念只拆真实操作链从models.py第一行from django.db import models开始到生成可部署的迁移文件再到生产环境上线前必须做的三道数据校验关。2. 核心设计思路为什么Models不是“数据库表”的简单映射2.1 拆解标题动词“Jumping Into”的真实含义“Jumping Into”这个词组在技术语境里常被误读为“快速上手”或“跳过基础”但在Django Models的语境下它恰恰指向一种反直觉的设计哲学主动跳入约束而非绕开约束。很多初学者一上来就想实现“用户可以填任意长度的个人简介”于是写TextField()想让“订单金额支持小数”就写FloatField()看到“用户头像要上传”马上去查ImageField。结果呢开发阶段一切顺利上线两周后财务对账发现订单金额出现0.1 0.2 0.30000000000000004这种经典浮点误差导致分账失败运营导出用户数据时发现因为TextField没设blankTrue所有空简介字段在Admin后台显示为None而业务方要求“空简介”必须显示为空字符串更隐蔽的是当团队引入Redis缓存用户头像URL时ImageField自动生成的文件路径包含空格和中文导致CDN回源404。这些都不是Django的bug而是对Jumping Into的误读——它不是跳进功能实现的快车道而是跳进Django为你预设的、由Python类型系统、数据库约束、ORM行为三重加固的“安全围栏”。真正的“跳入”是主动接受DecimalField强制要求精度声明max_digits10, decimal_places2是理解blankTrue控制表单验证而nullTrue控制数据库存储是清楚ImageField底层依赖FileField其upload_to参数必须是纯ASCII路径。我去年重构一个老项目时把37个CharField里所有max_length255统一改成max_length191不是为了省几个字节而是为MySQL 5.7默认utf8mb4字符集下的索引长度限制埋下伏笔——这个决策当时没人理解直到三个月后添加联合唯一索引时191*3 767的报错让所有人闭嘴。Models的设计本质是用Python代码提前声明数据契约把未来可能爆发的混乱压缩在makemigrations这一步的终端输出里。2.2 Models在Django架构中的真实定位远不止是“表定义”把Models当成“数据库表的Python版说明书”是新手最大的认知陷阱。Django的Models层实际承担着三层不可替代的职责每一层都直接影响后续所有环节第一层数据契约层Data Contract Layer这是最基础也最关键的职能。models.CharField(max_length50)不仅告诉PostgreSQL“这个字段最多存50个字符”更向整个Django生态发出强信号任何试图通过User.objects.create(namea*100)创建实例的操作在Python层面就会被ValidationError拦截如果走ModelForm或在save()时抛出DataError如果直调save。这种契约是双向的它既约束写入也保障读取——当你调用user.name.upper()时IDE能准确推断返回类型是str而不是Optional[str]。我见过最典型的反模式是某电商项目把“商品SKU”定义为TextField()理由是“SKU规则未来可能变”。结果半年后搜索功能因全文索引性能暴跌被砍掉库存同步服务因无法建立高效索引频繁超时最后被迫停服三天做数据清洗。如果当初用CharField(max_length64)并配合数据库UNIQUE约束这些问题本可避免。第二层业务逻辑锚点层Business Logic Anchor LayerModels是Django中唯一能天然承载“与数据强耦合业务规则”的地方。get_full_name()方法、is_active属性、order_total的property计算这些不是装饰而是将业务语义固化在数据结构上的关键锚点。重点在于“强耦合”——比如“用户积分过期规则”如果写在views.py里下次做APP推送时就得再抄一遍逻辑如果写在serializers.py里API返回积分时又得维护一份。只有写在Model的property或自定义Manager方法里才能保证user.points_expired_at在Admin、API、管理脚本、Celery任务中始终一致。我们团队有个硬性规定所有涉及单个Model实例的计算逻辑必须出现在该Model内部否则Code Review直接拒绝。这条规则让我们的订单状态机从17个散落函数收敛为3个Model方法测试覆盖率从42%升至91%。第三层系统集成枢纽层System Integration HubModels是Django连接外部系统的神经中枢。ImageField自动对接DEFAULT_FILE_STORAGEForeignKey触发on_delete级联行为JSONField无缝支持PostgreSQL的JSONB操作符GenericForeignKey打通多态关联。更重要的是它为第三方库提供标准接入点Django REST Framework的ModelSerializer、Django Filter的FilterSet、Django Debug Toolbar的SQL分析全部依赖Models的元数据_metaAPI动态生成。当你看到django celery 如何使用redis集群版这类热搜时背后真正起作用的是TaskResult这个Model如何通过Meta.db_table指定分片表名如何用JSONField存储result字段以适配Redis的序列化协议。忽略Models的枢纽作用就像想修高铁却不研究轨道接口标准。2.3 为什么“零基础入门”必须从Models切入网络上充斥着“Python零基础入门教程”“django框架入门”这类泛泛而谈的内容但真实项目启动时95%的阻塞点都发生在Models层。原因很现实反馈链最短写一个views.py视图要配URL、写模板、启服务、开浏览器耗时5分钟改一个models.py字段执行python manage.py makemigrations python manage.py migrate终端输出3秒内见分晓。这种即时反馈对建立信心至关重要。错误最直观FieldError: Unknown field user_nam比AttributeError: NoneType object has no attribute id更容易定位。前者明确告诉你“模型里没这个字段”后者可能源于10个模块的空值传递。影响面最可控修改视图可能牵扯前端路由改模板可能影响SEO但Models的变更只要做好迁移影响范围严格限定在数据层。我们团队新人的第一个PR永远是“添加UserProfile模型并关联User”因为这是唯一能独立验证、无副作用、且直接体现业务价值的起点。所以“Jumping Into Django Models”不是学习路线图上的一个节点而是整个Django开发范式的入口。它强迫你用结构化思维思考问题一个“用户”到底由哪些原子属性构成哪些属性必须存在哪些可以为空哪些值之间存在逻辑依赖这种思维一旦建立后续的Views、Templates、APIs都会变得水到渠成。3. 核心细节解析从字段定义到迁移策略的硬核要点3.1 字段类型选择不只是“存什么”更是“怎么用”Django字段类型的选择表面看是数据类型匹配深层决定的是查询效率、存储成本、业务扩展性。下面按实战优先级排序详解最易踩坑的字段CharFieldvsTextField长度即契约不是任性CharField要求max_lengthTextField不要求但这绝非“长文本就用TextField”的懒人逻辑。真实场景中CharField(max_length191)是MySQL 5.7 utf8mb4字符集下唯一能建全文索引的字符串类型。我们曾有个搜索功能把“商品标题”设为TextField结果SELECT * FROM product WHERE title LIKE %手机%全表扫描QPS从1200跌到80。改成CharField(max_length191)并加db_indexTrue后响应时间从2.3s降至47ms。TextField真正的战场是“用户评论正文”“文章内容”这类无法预估长度、且极少用于WHERE条件的字段。记住铁律凡需参与WHERE、ORDER BY、GROUP BY或建索引的字符串字段必须用CharField并精确设定max_length。IntegerFieldvsBigAutoFieldvsUUIDField主键选择决定系统寿命新项目默认id models.AutoField(primary_keyTrue)这在中小项目够用但一旦日均订单超5万IntegerField的21亿上限会让你在凌晨三点收到告警。我们线上一个SaaS平台主键从AutoField升级到BigAutoField时发现Django 3.2已默认使用BigAutoField但遗留的ForeignKey未同步更新导致外键字段仍是IntegerField迁移时爆IntegrityError。解决方案是显式声明class Meta: default_auto_field django.db.models.BigAutoField更激进的选择是UUIDField它牺牲了自增ID的简洁性换来分布式ID生成能力。但注意UUIDField默认生成CHAR(32)比BIGINT多占24字节且索引碎片率更高。我们只在微服务间需要全局唯一标识的场景如订单号、支付流水号才用UUIDField并配合defaultuuid.uuid4和editableFalse。DateTimeField的时区陷阱auto_now是蜜糖也是毒药auto_now_add和auto_now看似方便实则暗藏杀机。auto_now_addTrue会在首次保存时自动设置但无法通过ModelForm修改auto_nowTrue每次保存都覆盖导致“最后编辑时间”无法人工修正。更致命的是它们强制使用timezone.now()在跨时区部署时若服务器时区设为UTC而业务要求东八区所有时间戳会偏差8小时。正确姿势是created_at models.DateTimeField(defaulttimezone.now, editableFalse) updated_at models.DateTimeField(auto_nowTrue) # 仅此处可用auto_nowdefaulttimezone.now注意无括号确保每次实例化都调用当前时间editableFalse防止Admin误改而updated_at保留auto_now的便利性——因为“最后更新时间”本就不该由人干预。JSONFieldPostgreSQL的宝藏SQLite的鸡肋JSONField在PostgreSQL上是真·神器支持__contains、__has_key等查询甚至能用-操作符提取嵌套值。但在SQLite上它只是TextField的包装所有JSON操作都在Python层完成无法利用数据库索引。我们有个配置中心项目初期用SQLite开发config_data models.JSONField()写得飞起上线PostgreSQL后发现SELECT * FROM config WHERE config_data-env prod快如闪电但config_data字段本身无法建索引。最终方案是对高频查询的JSON键如env,region额外建CharField冗余存储并用save()方法自动同步用空间换时间。3.2 关系字段深度解析ForeignKey、ManyToManyField、OneToOneField的实战边界关系字段是Models的灵魂但也是新手混淆重灾区。关键不是语法而是数据所有权和生命周期管理。ForeignKey谁拥有谁决定了删除逻辑on_delete参数不是摆设。models.CASCADE级联删除适用于“强拥有关系”如OrderItem属于Order删订单必删明细models.PROTECT保护适用于“弱引用关系”如UserProfile.country引用Country表删国家前必须确保无用户关联最易被忽视的是models.SET_NULL它要求字段nullTrue适用于“可选归属”如Article.author可设为NULL表示“匿名作者”。我们曾有个BugComment.post用CASCADE但Post被软删除is_deletedTrue而非真删导致评论也被级联删掉。解决方案是改用models.SET_DEFAULT并设default0虚拟“已删除”帖子ID或引入django-model-utils的SoftDeletableModel。ManyToManyField中间表不是魔法是可控的实体ManyToManyField自动生成中间表但当需要存储关联元数据时如“用户收藏文章的时间”“课程学生评分”必须显式定义中间模型class UserCollection(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) article models.ForeignKey(Article, on_deletemodels.CASCADE) collected_at models.DateTimeField(defaulttimezone.now) rating models.PositiveSmallIntegerField(default0) class Meta: unique_together (user, article) # 防止重复收藏此时User.collections.through指向UserCollection所有操作添加、查询、删除都可通过UserCollection.objects直接进行完全掌控。OneToOneField不是“一对一”而是“扩展表”OneToOneField的核心价值是垂直拆分大表。当User模型字段超30个且部分字段如last_login_ip,failed_login_count访问频次极低时拆到UserSecurityProfile能显著提升高频查询性能。关键技巧OneToOneField默认on_deletemodels.CASCADE但若主表User可能被软删除应设on_deletemodels.SET_NULL并nullTrue避免扩展表数据丢失。3.3 Meta类配置被低估的生产力引擎class Meta:不是装饰而是Django ORM的“编译指令”。以下配置直接影响开发效率和运行时行为db_table和db_column精准控制数据库命名默认db_tablemyapp_mymodel但遗留系统或DBA要求时必须显式指定class Meta: db_table t_user_profile # 符合公司命名规范 db_column user_id # 字段物理名注意db_column只影响该字段的数据库列名不影响Python属性名。ordering全局默认排序减少重复代码ordering [-created_at]会让MyModel.objects.all()默认按创建时间倒序。但切记它不适用于分页场景Paginator在QuerySet上切片时若未指定order_by()Django会警告“Pagination may yield inconsistent results”。正确做法是MyModel.objects.all().order_by(-created_at)显式调用。indexes为高频查询定制索引indexes [models.Index(fields[status, created_at])]会生成复合索引加速filter(statusactive).order_by(-created_at)。但索引不是越多越好每增加一个索引INSERT/UPDATE速度下降约5%-10%。我们通过django-sql-explorer监控慢查询只为WHERE ORDER BY组合出现超100次/天的字段建索引。constraints数据库级约束最后一道防线CheckConstraint(checkmodels.Q(price__gte0), nameprice_non_negative)在数据库层强制价格非负比Python层clean()方法更可靠。但注意SQLite不支持CHECK约束PostgreSQL 12才支持EXCLUDE约束如“同一用户不能在同一时间段预约两个会议室”。4. 实操过程从零构建一个可上线的Models体系4.1 场景设定一个真实的“用户积分系统”需求假设我们要开发一个积分商城核心需求如下用户注册即获100积分每日签到5积分连续签到第7天额外20购买商品按订单金额1:1兑换积分1元1积分积分可兑换优惠券每张券消耗固定积分所有积分变动需留痕支持审计这个需求看似简单但暴露出Models设计的典型挑战状态分散、事务一致性、历史追溯。我们将用实战方式一步步构建健壮的Models。4.2 第一步定义核心模型与字段models.py# models.py from django.db import models from django.contrib.auth.models import User from django.core.validators import MinValueValidator from django.utils import timezone class UserProfile(models.Model): 用户扩展资料垂直拆分User表 user models.OneToOneField(User, on_deletemodels.CASCADE, related_nameprofile) avatar models.ImageField(upload_toavatars/, blankTrue, nullTrue) bio models.CharField(max_length200, blankTrue) # 积分余额冗余字段提升查询性能 points_balance models.PositiveIntegerField(default0, help_text当前可用积分) def __str__(self): return f{self.user.username}s profile class PointsLog(models.Model): 积分流水日志不可变事实表 TYPE_CHOICES [ (SIGN_IN, 签到), (ORDER, 订单), (COUPON_USE, 兑换优惠券), (ADMIN_ADJUST, 管理员调整), ] user models.ForeignKey(User, on_deletemodels.CASCADE, related_namepoints_logs) points_change models.IntegerField(help_text积分变动值正为增加负为减少) balance_after models.PositiveIntegerField(help_text变动后余额) log_type models.CharField(max_length20, choicesTYPE_CHOICES) description models.CharField(max_length200, blankTrue) # 外键关联具体业务对象可选 order_id models.CharField(max_length32, blankTrue, nullTrue, db_indexTrue) coupon_code models.CharField(max_length32, blankTrue, nullTrue, db_indexTrue) created_at models.DateTimeField(defaulttimezone.now, db_indexTrue) class Meta: ordering [-created_at] indexes [ models.Index(fields[user, -created_at]), models.Index(fields[log_type, created_at]), ] def __str__(self): return f{self.user.username} {self.points_change:d} points ({self.get_log_type_display()}) class Coupon(models.Model): 优惠券定义 code models.CharField(max_length32, uniqueTrue, db_indexTrue) name models.CharField(max_length100) points_required models.PositiveIntegerField(validators[MinValueValidator(1)]) discount_amount models.DecimalField(max_digits10, decimal_places2) is_active models.BooleanField(defaultTrue) valid_from models.DateTimeField() valid_to models.DateTimeField() def __str__(self): return self.code提示PointsLog的balance_after字段是关键设计。它冗余存储变动后余额避免每次查询余额都要聚合全量流水将O(n)降为O(1)。虽然增加了存储但换来的是高并发场景下的稳定性。4.3 第二步编写迁移文件并理解其生成逻辑执行python manage.py makemigrationsDjango会生成类似0001_initial.py的文件。打开它你会看到# migrations/0001_initial.py from django.db import migrations, models import django.core.validators import django.db.models.deletion import django.utils.timezone class Migration(migrations.Migration): initial True dependencies [ (auth, 0012_alter_user_first_name_max_length), # 依赖auth应用迁移 ] operations [ migrations.CreateModel( nameUserProfile, fields[ (id, models.BigAutoField(auto_createdTrue, primary_keyTrue, serializeFalse, verbose_nameID)), (avatar, models.ImageField(blankTrue, nullTrue, upload_toavatars/)), (bio, models.CharField(blankTrue, max_length200)), (points_balance, models.PositiveIntegerField(default0, help_text当前可用积分)), (user, models.OneToOneField(on_deletedjango.db.models.deletion.CASCADE, related_nameprofile, toauth.user)), ], ), # ... 其他CreateModel操作 ]关键洞察dependencies明确列出依赖的其他应用迁移确保执行顺序。若你手动修改了dependencies可能导致迁移冲突。operations是原子操作列表每个CreateModel、AddField都是独立事务。Django 4.2支持RunPython操作可用于数据迁移如初始化100积分。initial True表示这是该应用的首版迁移后续新增模型会生成0002_add_coupon.py等。4.4 第三步数据迁移与初始数据注入执行python manage.py migrate应用迁移。但此时新用户注册不会自动获得100积分——因为UserProfile是OneToOneField需在用户创建后手动创建。解决方案是Django信号# signals.py from django.db.models.signals import post_save from django.dispatch import receiver from django.contrib.auth.models import User from .models import UserProfile receiver(post_save, senderUser) def create_user_profile(sender, instance, created, **kwargs): if created: UserProfile.objects.create(userinstance, points_balance100) receiver(post_save, senderUser) def save_user_profile(sender, instance, **kwargs): instance.profile.save() # 确保profile存在并在apps.py中注册# apps.py from django.apps import AppConfig class PointsConfig(AppConfig): default_auto_field django.db.models.BigAutoField name points def ready(self): import points.signals # 导入信号模块注意信号虽方便但调试困难。对于关键业务如积分发放我们更倾向在UserCreationForm.save()中显式调用UserProfile.objects.create()确保逻辑可见、可测。4.5 第四步业务逻辑封装与事务安全积分变动必须保证ACID。以下是一个安全的签到逻辑# services.py from django.db import transaction from django.utils import timezone from .models import PointsLog, UserProfile def daily_sign_in(user): 用户每日签到返回是否成功及积分变动 today timezone.now().date() # 检查今日是否已签到使用数据库锁防并发 with transaction.atomic(): # SELECT FOR UPDATE 锁定用户记录 profile UserProfile.objects.select_for_update().get(useruser) # 查询今日是否有签到记录 today_log PointsLog.objects.filter( useruser, log_typeSIGN_IN, created_at__datetoday ).exists() if today_log: return False, 0 # 计算积分连续签到逻辑略 points 5 # 创建流水 PointsLog.objects.create( useruser, points_changepoints, balance_afterprofile.points_balance points, log_typeSIGN_IN, descriptionf每日签到 {points}积分, ) # 更新余额 profile.points_balance points profile.save() return True, points关键点transaction.atomic()确保流水创建和余额更新要么全成功要么全失败select_for_update()在数据库层加行锁防止高并发下重复签到。没有这个锁100个用户同时请求可能产生100条流水但余额只加5。4.6 第五步生产环境上线前的三道校验关上线前必须通过以下校验否则可能引发雪崩第一关迁移兼容性校验在测试环境执行python manage.py showmigrations确认所有迁移状态为[X]运行python manage.py sqlmigrate myapp 0001查看生成的SQL确认无DROP TABLE等危险操作。我们用django-migration-linter工具自动检测破坏性变更。第二关数据一致性校验编写校验脚本对比UserProfile.points_balance与PointsLog聚合结果# management/commands/validate_points.py from django.core.management.base import BaseCommand from points.models import UserProfile, PointsLog class Command(BaseCommand): def handle(self, *args, **options): for profile in UserProfile.objects.all(): actual PointsLog.objects.filter(userprofile.user).aggregate( totalmodels.Sum(points_change) )[total] or 0 if profile.points_balance ! actual: self.stdout.write(fERROR: {profile.user.username} balance mismatch!)上线前全量运行修复所有不一致数据。第三关索引有效性校验对PointsLog表检查user_id和created_at是否已建索引-- PostgreSQL SELECT indexname, indexdef FROM pg_indexes WHERE tablename points_pointslog;确保有points_pointslog_user_id_created_at_idx这样的复合索引。缺失索引会导致user.points_logs.all()查询超时。5. 常见问题与排查技巧实录那些让你熬夜的Models错误5.1 经典报错解析与根因定位报错信息根本原因排查步骤解决方案django.core.exceptions.FieldError: Unknown field xxx模型中未定义该字段或拼写错误1. 检查models.py中字段名2. 查看migrations/下最新迁移文件确认字段是否已添加3. 运行python manage.py showmigrations确认迁移已应用修正字段名或执行python manage.py makemigrations生成新迁移django.db.utils.IntegrityError: NOT NULL constraint failed: xxx.yyy字段设为nullFalse默认但插入时未提供值1. 查看报错表名和字段名2. 检查该字段的default值如default03. 检查ModelForm或API序列化器是否遗漏该字段添加default值或设nullTrue需评估业务意义django.core.exceptions.ValidationError: {field: [This field cannot be blank.]}blankFalse默认但表单提交空值1. 检查字段blank属性2. 查看ModelForm的fields是否包含该字段3. 检查前端是否发送了空字符串设blankTrue或在clean()方法中处理空值逻辑django.db.utils.ProgrammingError: relation xxx does not exist迁移未执行或dependencies错误导致执行顺序错乱1. 运行python manage.py showmigrations2. 检查报错表名对应的迁移文件是否在dependencies中声明执行python manage.py migrate或手动修复dependencies5.2 “all models are temporarily rate-limited. please try again in a few minutes.” 的真相这个错误与Django Models完全无关它是某些AI服务如OpenAI API的速率限制提示常因开发者误将Django项目与AI服务混用而出现。典型场景在views.py中调用requests.post(https://api.openai.com/v1/chat/completions)但API Key配错或额度用尽使用django-allauth时社交登录回调URL配置错误导致重定向到AI服务端点本地开发时.env文件误将OPENAI_API_KEY设为空触发服务端兜底限流排查方法检查报错堆栈确认是否来自requests或httpx库搜索项目中所有openai、anthropic、cohere等关键词查看settings.py中是否配置了相关API密钥临时注释掉所有外部API调用确认问题是否消失提示这个错误之所以高频是因为它常出现在“Django AI”教程的代码片段中新手复制后忘记替换API Key导致整个Django应用被误认为是AI服务的客户端。5.3 生产环境高频问题与避坑指南问题迁移文件冲突多人协作时0002_auto_xxx.py和0002_add_field.py同时存在根因两人基于同一版本分支开发各自生成了0002迁移。解决执行python manage.py makemigrations --name merge_conflict生成空迁移编辑新迁移文件将两个0002的operations合并到operations []中删除两个冲突的0002文件执行python manage.py migrate避坑强制要求PR前先git pull origin main并python manage.py migrate用django-migration-ci工具自动检测冲突。问题ForeignKey删除后Admin后台显示None而非对象名根因related_name未设置或__str__方法返回空字符串。解决class Order(models.Model): # ... def __str__(self): return fOrder #{self.id} - {self.user.username} # 确保返回非空字符串问题JSONField在SQLite上查询极慢根因SQLite不支持JSON函数Django在Python层解析整个JSON字符串。解决开发环境用PostgreSQLDocker一键启动对高频查询的JSON键建冗余CharField并用save()同步使用django-pgjsonb库仅PostgreSQL5.4 性能优化实操清单附基准测试数据我们对一个100万行的PointsLog表做了以下优化QPS从82提升至1890优化项操作QPS提升说明添加复合索引CREATE INDEX CONCURRENTLY idx_user_created ON points_pointslog (user_id, created_at DESC);320%加速user.points_logs.all().order_by(-created_at)分区表PostgreSQLCREATE TABLE points_pointslog_y2024 PARTITION OF points_pointslog FOR VALUES FROM (2024-01-01) TO (2025-01-01);210%按月分区查询只扫当前分区select_related优化PointsLog.objects.select_related(user).filter(...)180%减少N1查询一次JOIN获取用户信息only()字段精简PointsLog.objects.only(id, points_change, created_at)95%只取必要字段减少内存占用最后分享一个小技巧在settings.py中开启DEBUG True时Django Debug Toolbar会显示每条SQL的执行时间。但生产环境DEBUGFalse此时可在LOGGING配置中启用django.db.backends日志器将慢查询100ms自动记录到文件形成性能