gpt4 book ai didi

php - 没有重复条目时的mysql重复条目错误(通过php批量加载)

转载 作者:可可西里 更新时间:2023-11-01 06:49:25 24 4
gpt4 key购买 nike

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

  1. 截断一组 4 个“导入”表
  2. 将数据批量插入到这 4 个“导入”表中(重新使用以前在表中的 ID,但我截断了整个表,所以这应该不是问题,对吧?)
  3. 如果一切顺利,将“live”表重命名为“temp”,将“import”表重命名为“live”,然后将“temp”(旧的“live”)表重命名为“import”

这几个星期都很好用。现在我偶尔会在整个批量加载过程的某个地方得到这个:

SQLSTATE[23000]:违反完整性约束:1062 键 1 的重复条目“911”

请注意,这不是截断之前表中的第一个 ID。当我再次手动启动脚本时,它就像一个魅力。

有什么想法吗?剩余索引,可能与重命名有关?

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

最佳答案

当 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;

当然,如果您要插入非常多的行,那么风险是,只要插入完成,您所有的实时数据都不可用,但总的来说,这种方法对索引、触发器的破坏性要小得多或任何其他可能与相关表格相关联的内容。

关于php - 没有重复条目时的mysql重复条目错误(通过php批量加载),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/221399/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com