当恢复备份时，mysql错误1062'重复条目'

有这样的“重复”可能会发生的各种原因：

• 您的数据是敬酒。
• 一个使用自动增量插入的应用程序，但后来运行了一个UPDATE手动修改标识为一个不同的，可能存在的值。 这种情况有时会发生在应用程序开发人员正在按“ID”sorting并希望“修复sorting”（通过实际上破坏一致性）。
• 第二个问题的变化发生在后面添加非唯一logging插入后的“唯一”约束的人。

错误消息确实引用了第一个键，在大多数数据库模式中这是第一个键。 看看原始转储输出，特别是INSERT语句并检查

INSERT INTO ... values (0,...

扫描错误消息中给出的mysql转储的行号。

什么样的mysqldump我期待的例子：

 INSERT INTO foo (id,bar,baz) values (1,2,3); INSERT INTO foo (id,bar,baz) values (0,4,5); INSERT INTO foo (id,bar,baz) values (2,6,7); 

在自动增量字段的“正常”INSERT语句中，值“0”指定自动递增字段，因此不应在使用自动递增字段的数据库SQL转储中显示。 通过SQL转储重新加载数据库，转储会要求SQL Server将当前字段值递增1，并插入该ID。 如果有人在插入logging后手动更新身份为零，那么MySQL Dump也会包含这个奇怪的ID。

如果您正在将此转储重放到空表中，则会尝试创build以下logging：

 1,2,3 2,4,5 2,6,7 

由于“id”字段已被设置为唯一的自动增量，第二个INSERT将创build与以下logging冲突的“错误”logging（期望：0,4,5;实际：2,4,5）（id = 2 ），结果给出错误信息。

在这种变化中，某人“手动”地将身份更新为已经存在的值，并且稍后将logging更改为“唯一”。 如果当前数据符合要求，将loggingtypes更改为唯一不会使MySQL重新validation，从而导致延迟错误。 这种变化可能会创build一个像这样的转储：

 INSERT INTO foo (id,bar,baz) values (1,2,3); INSERT INTO foo (id,bar,baz) values (1,4,5); INSERT INTO foo (id,bar,baz) values (2,6,7); 

尝试插入第二行将由于唯一的约束而失败。

在这两种情况下，使用“–force”只会忽略“冲突”行并继续导入。 “冲突”的路线将会丢失，但可能导致冲突的线路将会在那里（但带​​有错误的logging）。

如果我的想法符合您的问题，请检查您的数据库转储。 如果是这样，这里有两个解决方法“使其工作”：

• 导入数据分两步进行，首先是模式，后面是数据。 在导入数据之前删除模式中的唯一约束，稍后再添加唯一约束（“ALTER TABLE … add unique …”）。

• 强制导入模式和所有数据，导致“不同的”约束问题。 手动检查哪些logging是正确的，并重新分配错误的原始值。

后面的问题的例子：

 mysql -uuser -ppass --execute "SET UNIQUE_CHECKS=0; source db3.sql" db4 

这强制导入所有冲突的logging，甚至违反任何真正的唯一约束。 导入后，这三条logging（600806,187694和1567400）将有多个条目，您必须通过检查您的转储来手动清理哪些是正确的，这些“重复”中的哪一个会导致冲突并手动更新错误的logging“回”为零（或任何转储冲突线说）。

在这两种情况下，您的数据仍然违反给定的模式：您的模式表示数据是唯一的，但事实并非如此。 从长远来看，数据需要在应用程序级别上进行修改。

首先，请检查所查询的行是否存在于原始数据库中的状态。

有可能是，发生了以下事情之一：

• 有问题的专栏/专栏在某一时刻并不是独一无二的，而是在稍后被修改。
• 这是一个你正在倾倒的从属数据库，并且在某些时候已经有一些binlog重放，并且插入了潜在的重复键
• 错误的SQL语句或导入的命令导致重复的条目。

如果只有3行显示问题，请更正它们的关键字段，如果可能的话，执行转储并导入该实例，查看错误是否不再出现。 我猜，它应该消失。

前言

所以我遇到这个问题后，我们的复制服务器进入一个不一致的状态。 我们无法迅速修复，并决定使用新备份重新初始化复制。

上面提到的问题不是同一个问题，但是会返回相同的错误，因此我决定添加这个答案以防其他人正在寻找它。

这也是DBA Stack Exchange上这个问题的确切副本，但是因为这个问题在（我的）Google结果中有更高的排名，所以我也在这里发布。

我们做了什么

我们使用MySQL Workbench删除了实例上的所有数据库，然后重新启动了实例，然后再次检查实例上没有数据库的位置。 在主服务器上，我们已经开始使用我们始终使用的脚本创build新的备份。

然后，一旦备份在失败的服务器上，我们开始导入，几个小时后，它已经导入了大部分数据，并失败，出现这些types的错误：

 ERROR 1062 (23000) at line XXX: Duplicate entry 'dbName-tblName' for key 'PRIMARY' Operation failed with exitcode 1 

我们以为好了，也许在创build备份时出了点问题，我检查了备份中的数据，但是找不到任何错误。 我们再次尝试所有的步骤，以确保我们没有错过任何东西，但不幸的是没有雪茄。

实际的问题

显示的错误不是数据的实际插入，而是创build索引。 这就是为什么数据插入没有问题（我们检查），但仍然产生了一个错误。 显然删除所有的表是不够的，索引数据仍然存在于服务器上（这可能是由于MySQL 5.6的变化，因为我们以前从来没有这个问题）。 而且由于这些索引的导入位于导入文件的中间，其余的数据不会被导入。

修复

我们删除了mysql数据库文件夹中的ibdata1文件和所有innodb_index_stats和innodb_table_stats文件，然后启动实例。 MySQL会告诉你一些系统表丢失， 你可以在这里find更多的信息

这解决了我们的问题，我们的服务器正在按预期进行复制。

希望这可以为某个地方节省一些时间:)