今天的文章，没有用过Django的同学可能难以理解我在说什么。但是如果你被Django的migration折腾过，那么你一定会感谢这篇文章。
当我们使用Django + MySQL开发网站服务的时候，我们应该始终使用Django来管理数据库，无论是增加字段，删除字段，修改字段，都应该直接修改Django工程 app里面对应的 models.py文件，不应该再手动直接修改数据库。
但这种理想的情况有时候会被打破。我最近遇到了这样一种情况：
出于安全考虑，我把线上的MySQL数据库禁用了 drop的权限。但由于我修改了 models.py文件中的字段，于是触发了 drop字段的操作，由于没有权限，导致Django在migration线上数据库的时候报错。
由于上线时间紧急，当时我直接通过执行SQL语句在线上MySQL中创建了对应的数据表和字段。
现在就出现问题了：
- 首先，Django的web服务能够正常工作，因为数据表是完全正确的。
- app的migration一共有10条，在进行到第6条的时候报错。剩下的4步无法继续执行。
- 数据库经过人工修改，看起来像是把所有migration都执行完的样子，但实际上最后4步是通过执行SQL语句手动创建的。
- 如果不增删改新的字段，那么到目前为止不会有什么问题。但是如果增加修改了新的字段，migration将会始终失败。除非每一次都手动修改数据库。
现在的情况就是数据库与Migration不一致，可以使用下面的命令重新同步migration和数据库。
# 清除迁移历史记录 python manage.py migrate --fake app_name zero # 查看当前的migration进度，此时文件前的 [x] 变成了[ ] python manage.py showmigrations app_name #删除app-migrations下除__init__.py的其他文件 #执行makemigrations，程序会再次为这个app 生成 0001_initial.py 文件 python manage.py makemigrations app_name # 把当前数据库的状态作为初始状态 python manage.py migrate --fake-initial app_name
从现在开始，你再次对数据库进行更改以后，重新make migration，所有新的操作都会基于当前的数据库状态继续进行，migration和数据库又重新同步了。
