Django 版本 1.9，先描述一下我遇到的问题。
# 假设这是我的 Model
class StudentCourse(models.Model):
user = xxx
course = xxx
class Meta:
unique_together = ('user', 'course')
我在修改 Model 时，不仅 Alter 了 unique_together，并且 Delete 了原来 unique_together 里的 column，造成 migrate 出错。
django.core.exceptions.FieldDoesNotExist: StudyRecord has no field named u'chapter'
# 假设这是我更改过后的 Model
class StudentCourse(models.Model):
human = xxx
some_stuff = xxx
class Meta:
unique_together = ('human', 'some_stuff')
照理来说，修改完 Model，makemigrations & migrate 即可。为什么会崩溃呢？
经过我的试错和分析，发现如果完全按照 Django 生成的 migration 文件来执行操作的话，顺序是存在问题的。
按照我上面的操作，Django 会先删除 user & course 这两个字段，再去 Alter unique_together，这个操作等于是在 Alter 一个不存在的 column ，那么就会崩溃。
正确的做法是，先 Alter constraint，然后再删除 user & course 。
涉及到 Django Model 的修改，尽量不把各种操作混在一起。这样也许麻烦，但最稳。如果你看得懂 Django 生成的 migration 文件，当然也可以自己调整顺序。
由于 migrate 崩溃了，此时 migrate 没有成功，我在检查数据库后发现 column 也没有被删除。接着我开始恢复。
我把错误的 migration 文件删除，修改 Model ，此时新增 human & some stuff 两个字段，并且修改了 unique_together， makemigrations & migrate。
删除 user & course，makemigrations & migrate ，问题解决。
此外，还有一个 migrate 指令可以了解一下。
python manage.py migrate --fake your_app_name your_migration_name
这个指令是做什么用的呢？Django 在每次 migrate 成功以后，会存储项目中各个 app 的 migrate 状态，比如我成功 migrate 了 0055_auto_xxx 文件，它就会给这个里程碑打个勾，记录你 migrate 到了这里。（应该还有其它用处，我没深入了解）
如果你有回退的需要，可以将 your_migration_name 替换为你的 migration 文件名，然后在不同状态之间切换。
去掉 --fake 的话，就是真实的回退。恭喜你踏出从删库到跑路的第一步。
对了，这个指令可以显示你项目的 migration 状态，正常情况下应该都是 x，表示你项目里的 app 都执行过了 migrate 。
python manage.py showmigrations
