问题描述：
已有的model，修改之后，想重新建模，于是将migrations文件夹中除__init__.py之外其他文件都删掉，再次执行以下步骤python manage.py makemigrations确认成功，执行python manage.py migrate，提示No migrations to apply. 表示一脸懵逼。再次修改，指定表名，再次尝试，发现问题依旧，表示二脸懵逼
排查过程
-
python manage.py dbshell进到数据库里面，查看是否表已存在
结果：表不存在 - 检查migrations文件
结果：文件没问题 - 百度 google 各种搜，乱投医，各种尝试
解决方案
-
python manage.py dbshell进到数据库中，执行delete from django_migrations where app='your_appname'; -
python manage.py makemigrations(若migrations文件未删除，可不执行这一步) -
python manage.py migrate好啦，大功告成
原因分析
- 查看django_migrations表结构
建表语句：CREATE TABLE "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL); - 原因
造成多次应用migrations失败的原因是，当前model是修改过的，原来的migrations已经被我删除，但是，重新生成的migrations使用递增整数记名，所以，在django_migrations表中0001，0002等前面几个数字的文件都已被记录，在Django看来，被记录了就相当于已应用，所以，会出现刚开始的No migrations to apply.
避免方案
- 有强迫症删除migrations文件的同学(比如我)，请同时到数据库中删除相应记录
- 没有强迫症的同学，可以继续生成新的migrations，旧的就不必理会了
题外话
执行python manage.py migrate之后，可以使用python manage.py sqlmigrate appname migrations_num(例如python manage.py sqlmigrate user 0002)查看当前migrations文件对应的sql语句。
另外，在使用上述命令查看0002文件的sql语句时发现，django会新建一个表user_new，然后插入user表中的数据，再把user表删掉，再把user_new重命名为user。所以，修改model的时候，不必担心原有数据会丢失。