百木园问题描述： 已有的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的时候，不必担心原有数据会丢失。————————————————版权声明：本文为CSDN博主「Jessie-via」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/qq_25730711/article/details/60327344
来源：https://www.cnblogs.com/yifengyu/p/14865576.html
图文来源于网络，如有侵权请联系删除。