我之前也碰到过几乎一模一样的情况！虽然你已经做了禁用外键检查、确保数据类型一致这些操作，但还是有几个容易被忽略的细节会导致这个问题，咱们一步步来排查解决：

• 确认外键检查是否真正全局生效
  有时候你执行了SET FOREIGN_KEY_CHECKS = 0;，但如果恢复过程开启了新的会话（比如用图形工具分步骤操作），这个设置就会失效。建议把禁用语句和恢复命令放在同一个会话里执行：

  mysql -u your_username -p -e "SET FOREIGN_KEY_CHECKS=0; SOURCE /path/to/your/backup.sql;"
  

  要是用图形化工具，记得先执行禁用语句，再立刻执行恢复，不要中途切换会话。

• 检查备份文件的表创建与数据插入顺序
  哪怕禁用了外键检查，InnoDB在某些场景下还是会“较真”——比如如果备份里先创建了bookmarks表（它依赖users和videos），再创建被引用的表，或者先插入bookmarks的数据再插入users/videos的数据，就可能触发约束错误。
  你可以打开备份文件看看：

  1. 先确保users和videos表的CREATE TABLE语句在bookmarks之前
  2. 数据插入部分，先插users、videos的数据，再插bookmarks的数据

• 额外禁用唯一检查与自动提交
  有些时候光禁用外键检查不够，加上这两个参数能解决隐性的约束校验问题：

  SET FOREIGN_KEY_CHECKS = 0;
  SET UNIQUE_CHECKS = 0;
  SET AUTOCOMMIT = 0;
  

  恢复完成后再执行：

  SET FOREIGN_KEY_CHECKS = 1;
  SET UNIQUE_CHECKS = 1;
  SET AUTOCOMMIT = 1;
  

• 核对字符集与排序规则
  数据类型一致不代表字符集和排序规则也一致！如果users.id、videos.id和bookmarks里对应的外键字段字符集/排序规则不同，也会触发约束失败。用下面的语句检查：

  SHOW CREATE TABLE users;
  SHOW CREATE TABLE videos;
  SHOW CREATE TABLE bookmarks;
  

  对比输出里的CHARSET和COLLATE字段，确保完全匹配。

• 检查备份里的外键约束定义时机
  有些备份工具会把外键约束单独抽出来，在所有数据插入完成后再添加；但如果你的备份里是在创建bookmarks表时就定义了外键，或者在数据插入前就执行了ALTER TABLE ADD FOREIGN KEY语句，那即使禁用了外键检查，执行到这些语句时还是会校验现有数据。
  这种情况下可以暂时注释掉备份里的外键约束语句，等所有数据恢复完成后，再手动执行ALTER TABLE语句添加外键。

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