当没有重复条目时mysql重复条目错误（通过php批量加载）

发布于 2024-07-07 06:06:08 字数 651 浏览 11 评论 0原文

我正在使用 mysql (5.0.32-Debian_7etch6-log) 并且我有一个每晚运行的批量加载 php (5.2.6) 脚本(使用 Zend_DB (1.5.1) 通过 PDO），它执行以下操作：

截断一组 4 个“导入”表
将数据批量插入到这 4 个“导入”表中（也重新使用之前在表中的 id ，但我截断了整个表，所以这不应该是一个问题，对吧？）
如果一切顺利，将“live”表重命名为“temp”，将“import”表重命名为“live”，然后将“temp” ”（旧的“实时”）表“导入”

这几周以来效果很好。现在，在整个批量加载过程中间的某个地方，我偶尔会遇到以下情况：

SQLSTATE[23000]: Integrityconstraint Violation: 1062 Duplicate entry '911' for key 1

请注意，这不是截断之前已经存在于表中的第一个 id。当我再次手动启动脚本时，它就像一个魅力。

有任何想法吗？剩余索引，可能与重命名有关？

另外，当我事后检查表中是否有 id 为 911 的条目时，它甚至不在那里。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

写下不归期 2024-07-14 06:06:09

您正在创建一条省略“id”字段（或 NULL）的新记录，
但之前您已经更新了另一条记录并将其“id”更改为“911”。
换句话说，如果采用表的 AUTO_INCRMENT 值，则无法创建另一条记录。

回复收藏 0 原文

凡尘雨 2024-07-14 06:06:08

当 MyISAM 表损坏时，可能会发生此类错误。通常只需在有问题的表上运行修复命令即可修复它：

> repair table mytablename;

更好的解决方案是不要对数据不断变化的表使用 MyISAM - InnoDB 更加安全，正如 Paul 正确指出的那样，您可以在 InnoDB 表上使用事务，但不能在 MyISAM 上使用事务。

顺便说一句，我会避免动态重命名表 - 这是定期执行的相当笨重的事情，并且如果在重命名过程中系统上有其他用户，可能会导致一些非常意外的结果。为什么不这样做：

> truncate table temptable;
> truncate table importtable;

> #bulk insert new data
> insert into importtable(col1,col2,col3) 
> values(1,2,3),(4,5,6),(7,8,9);

> #now archive the live data
> insert into temptable(col1,col2,col3)
> select col1,col2,col3 from livetable;

> #finally copy the new data to live
> truncate table livetable;
> insert into livetable(col1,col2,col3)
> select col1,col2,col3 from importtable;

当然，如果您要插入大量行，那么风险是，只要插入完成，所有实时数据都不可用，但总体而言，这种方法要少得多对索引、触发器或可能链接到相关表的任何其他内容具有破坏性。

Errors like this can occur when a MyISAM table becomes corrupt. Running the repair command on the table in question is usually all that's required to fix it:

> repair table mytablename;

A better solution is not to use MyISAM for tables where the data is constantly changing - InnoDB is much more bulletproof, and as Paul correctly points out, you can use transactions on InnoDB tables, but not on MyISAM.

By the way, I would avoid renaming tables on the fly - that's a fairly clunky thing to be doing on a regular basis, and could cause some very unexpected results if you ever have other users on the system while the renaming is going on. Why not just do something like this:

> truncate table temptable;
> truncate table importtable;

> #bulk insert new data
> insert into importtable(col1,col2,col3) 
> values(1,2,3),(4,5,6),(7,8,9);

> #now archive the live data
> insert into temptable(col1,col2,col3)
> select col1,col2,col3 from livetable;

> #finally copy the new data to live
> truncate table livetable;
> insert into livetable(col1,col2,col3)
> select col1,col2,col3 from importtable;

Of course if you are inserting a very large number of rows then the risk would be that all of your live data is unavailable for as long as the insert takes to complete, but overall this approach is far less destructive to indexes, triggers or anything else that may be linked to the tables in question.

回复收藏 0 原文