web2py运行db.py触发Duplicate column name重复列名错误求助

报1060 Duplicate column name错误不是你db.py里重复定义了同名字段，核心是PyDAL（web2py自带的ORM层）的自动迁移元数据和数据库实际结构不一致，迁移快照损坏了。
你之前删表、恢复备份都没解决，问题根本不在数据库本身，也不存在需要特殊清理的神秘缓存——PyDAL会在应用的databases目录下存所有表结构变更的快照文件，每次启动跑define_table的时候，会先对比快照和代码里的字段定义生成改表SQL，一旦快照文件损坏、或者快照和实际库的结构版本对不上，就会生成“给已经存在的列重复加字段”的错误SQL，你把当前报错表的字段删了，逻辑走到下一个表还是会触发同样的问题，所以错误会顺延。

操作前先停掉PythonAnywhere上的web进程，避免进程持有旧状态锁文件：

• 先全量备份你的应用目录和数据库，防止操作失误丢数据
• 进入web2py应用路径，打开applications/[你的应用名]/databases/目录，删除该目录下所有sql_*.table格式的迁移快照文件，不要删除同目录下的sql.log文件和storage文件夹（存上传文件的）
• 登录MySQL控制台，把该应用对应的所有业务表全部DROP删除，包括之前删了一半残留的结构不完整的表
• 检查db.py里的DAL初始化配置，确认没有全局设置migrate=False，所有define_table也没有单独加migrate=False参数
• 重启web进程，第一次访问应用时PyDAL会按照db.py里的定义重新创建所有表、生成新的正确迁移快照，错误会直接消失。

如果数据库里有重要数据不能全删重建，可以用fake迁移修复元数据：

1. 找到db.py里初始化DAL连接的代码行，加上fake_migrate_all=True参数，示例：

   db = DAL('mysql://你的数据库连接地址', fake_migrate_all=True)
   

2. 访问一次应用首页，这个参数会让PyDAL不实际执行任何改表SQL，只根据当前db.py里的表定义重新生成全量匹配的迁移快照文件
3. 回到db.py删掉刚才加的fake_migrate_all=True参数，再重启应用正常访问即可。

   注意：这个方案生效的前提是你当前数据库里的实际表结构，和db.py里写的字段定义完全一致。如果之前的错误已经把表结构改乱了，这个方法没用，还是要走前面的清快照+重建表流程。

• 只删单个报错表没用：损坏的迁移快照还存在，PyDAL的错误迁移逻辑不会变，处理完当前表走到下一个表还是会生成重复加列的SQL
• 仅恢复数据库备份没用：如果恢复数据库时没有同步清理/匹配databases目录下的迁移快照，快照版本和恢复后的库结构不匹配，还是会触发错误
• 删db.py里的字段没用：错误是迁移逻辑误判表中不存在某列才会重复加，和你代码里写多少字段没有关系，删字段只会把错误抛给下一个表。

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