现有项目中修改Django数据表主键的最佳方法

你拟定的全手动建表-拷数据-删表-重命名方案逻辑上可行，但对新手来说容错率极低，不推荐直接在生产环境执行，很容易出现数据不一致、关联关系断裂、长事务锁表拖垮业务的问题。

关于你提到的三个具体疑问 #

1. 自动生成迁移文件后手动调整是否合规可行？ #

完全可行，这也是Django官方推荐的生产环境表结构变更方式，比你纯手写外部脚本拷表的风险低很多。
操作时注意几个关键点：

• 先修改Model里的主键定义，同步调整所有关联模型的外键字段指向，再执行python manage.py makemigrations生成初始迁移文件，此时不要直接执行migrate命令
• 打开自动生成的迁移文件，补充RunPython类型的操作段：自动生成的迁移只会调整表结构，不会帮你完成旧数据到新主键的映射、关联表外键值的更新，这部分逻辑需要你手动补在迁移里
• 数据迁移逻辑不要用Model.objects.all()一次性加载全量数据，数据量大的时候必须加iterator(chunk_size=1000)分批读取，避免内存溢出
• 迁移文件本身是在数据库事务中执行的，只要你没提前关闭事务，中途出问题会自动回滚，比单独跑外部脚本的兜底能力强很多

2. 关联表能否自动识别重命名后的新表？直接删旧表会不会断关联？ #

绝对不会自动识别，直接删旧表100%会引发故障。
数据库层面的外键约束是直接绑定原表的物理表名、原主键字段的，你新建的表哪怕名字和旧表完全一致，原有外键约束也不会自动指向新表。如果保留了级联删除配置，删旧表时会直接把所有关联表的对应数据全部清空；就算关了级联删除，外键指向的表不存在后，所有关联查询、写入都会直接抛错。
如果坚持走你原来的手动方案，必须在删旧表之前先删除所有关联表指向旧表的外键约束，等新表重命名完成、数据校验通过后，再重新创建指向新表新主键的外键约束，手动操作很容易漏改多对多中间表、隐式关联的表，风险极高。

3. 手动操作时要不要提前移除级联删除配置？ #

必须提前处理，而且不止要关级联删除：

• 操作前先临时调整所有关联外键的on_delete规则，同时在数据库层面临时关闭外键约束检查：MySQL执行SET FOREIGN_KEY_CHECKS = 0;，PostgreSQL临时禁用外键触发器，避免删旧表时触发级联删除
• 所有操作完成、数据和关联关系全部校验通过后，再把外键约束、级联规则恢复，不要长期关闭约束
• 任何改表操作前必须做全量数据库备份，这是你唯一的兜底方案，不要相信任何脚本的正确性

给新手的低风险落地操作流程 #

比你原方案的出错概率低很多，按顺序走就行：

• 第一步：拉取生产库的全量备份恢复到测试环境，所有操作先在测试环境完整跑通，确认数据条数一致、关联关系正确、业务功能无异常后，再操作生产环境，绝对不要直接在生产上试错
• 第二步：优先走Django原生迁移流程，不要手动写建表删表逻辑：
  • 修改主表模型的主键字段定义，同步调整所有关联模型的外键配置
  • 执行makemigrations生成初始迁移，补充RunPython数据迁移逻辑，分批完成主表数据迁移、关联表外键值更新
  • 测试环境执行完迁移后，做全量数据校验：核对主表新旧数据条数，抽查至少上百条关联数据，确认外键映射没有错位
• 第三步：生产操作选业务低峰期，执行前再做一次全量备份，操作时临时切维护页停掉业务写入，避免迁移过程中新进数据丢失
• 第四步：迁移完成后不要立刻删除旧表、旧主键字段，先把旧主键保留为普通字段跑1-2周，确认所有业务逻辑无异常后，再生成迁移清理冗余字段和表

核心风险提示：数据量超过1万条时绝对不要一次性全量加载数据做迁移，必须分批处理，避免长事务锁表导致业务长时间不可用；主键修改是数据库最高危的操作类型之一，跳过测试环节直接上生产，出现数据丢失的概率极高。

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