我把这个挤在这里: 我的案例是试图为一个帖子创建一个喜欢的力量存在; 当提交到数据库时，错误被引发。 解决方案是首先创建帖子，然后喜欢它。 根据我的理解，如果post_id要保存在喜欢表，它必须首先与posts表检查，以确定存在。 我发现这样更好，因为这样对我来说更合乎逻辑。

这个错误通常发生是因为我们在子表的引用字段中有一些值，这些值在父表的引用/候选字段中不存在。

有时，当我们将外键约束应用到已有的表，其中已经有数据时，我们可能会得到这个错误。其他一些答案建议从子表中完全删除数据，然后应用约束。但是，当我们已经在子表中有工作/生产数据时，这不是一个选项。在大多数情况下，我们需要更新子表中的数据(而不是删除它们)。

现在，我们可以利用左连接来查找子表中的所有行，这些行在父表中没有匹配值。下面的查询将有助于获取那些不匹配的行:

SELECT child_table.* 
FROM child_table 
LEFT JOIN parent_table 
  ON parent_table.referenced_column = child_table.referencing_column 
WHERE parent_table.referenced_column IS NULL

现在，您通常可以执行以下一个(或多个)步骤来修复数据。

根据您的“业务逻辑”，您将需要用父表中的现有值更新/匹配这些不匹配的值。有时也需要将它们设置为空。 删除这些值不匹配的行。 在父表中添加新行，对应于子表中不匹配的值。

一旦数据固定，我们就可以使用ALTER TABLE语法应用外键约束。

外键表中存在一个主键表中不存在的值，因此必须先删除所有数据/根据主键中的值调整外键表的值

只是要找别的东西。如果您必须从一个表中删除记录，并期望值从1开始，那么您可能会得到这个错误。解决方案是在所有父表上运行SHOW * FROM表名。当我这样做的时候，我注意到在其中一个表中，我有一个问题，必须删除一些记录，主键值不是我所期望的，从以前的SELECT *。

在我的例子中，表格完全一致。

不管怎样，我得到这个错误是因为我(意外地)在同一个字段上创建了多个FK约束。

我运行下面的查询来显示所有的键:

SELECT *
FROM information_schema.table_constraints
WHERE constraint_schema = 'my_db_name'

我用以下查询删除了错误的:

ALTER TABLE my_table
DROP FOREIGN KEY wrong_fk_constraint; 

你也可以运行这个查询来检查它:

SHOW CREATE TABLE my_table;

我发现，在我尝试做我知道是正确的代码之前，将外键从非空改为空。帮助我使用Mysql工作台。我还必须设置set FOREIGN_KEY_CHECKS=0;然后回到=1;后完成。