mysql копируют ошибку записи, когда нет никакой дублирующейся записи (объемная загрузка через php)

Ошибки как это могут произойти, когда таблица 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;

Конечно, при вставке очень большого количества строк затем, риск состоял бы в том, что все живые данные недоступны столько, сколько вставка берет для завершения, но в целом этот подход является намного менее разрушительным к индексам, триггерам или чему-либо еще, что может быть связано с рассматриваемыми таблицами.

Некоторый другой сценарий мог вставлять в базу данных, в то время как Ваш сценарий импорта работает?

Вы попытались позволить журналу запросов видеть, вставляете ли Вы действительно дубликат?

Можно ли воспроизвести его в тестовой среде? Не включайте журнал запросов в производстве.

Возможно, что таблица была повреждена, если проблема подлинная; это могло быть вызвано многими вещами, но изворотливые аппаратные средства или сбой питания являются возможностями.

Проверьте журнал mysql, чтобы видеть, имел ли он какие-либо проблемы (или отказал), недавно или в течение периода.

Снова, все, что я могу предложить, должно попытаться воспроизвести его в Вашей тестовой среде. Создайте очень большие загрузки данных тестирования и неоднократно загружайте их.

По-видимому, были некоторые проблемы блокировки или что-то, я смог воспроизвести поведение путем стрельбы в операторы 'SELECT' к затронутым и связанным таблицам в параллельном соединении.

теперь я использовал DELETE FROM вместо TRUNCATE и измененный RENAME TABLE операторы (то, где я сделал 3, переименовывает сразу каждого) к набору сингла ALTER TABLE xxx RENAME TO zzz операторы и не могут больше воспроизводить ошибку.

таким образом, это могло бы быть решено. возможно, кто-то еще может получить прибыль с моего дня, проведенного с исследованием и большой пытаться-ошибкой.

Вы используете транзакции? Можно устранить много этих видов проблем с транзакциями, особенно если возможно или заблокировать таблицы или установить режим изоляции транзакции на сериализуемый. Я не действительно знаком с теми, которые на MySQL, но я полагаю, что транзакции только работают над таблицами InnoDB (или это могло быть устаревшим знанием).

Вы создаете новую запись с опущенным полем 'id' (или NULL), НО ранее вы обновили другую запись и изменили ее идентификатор на 911. Другими словами, вы не можете создать другую запись, если используется значение AUTO_INCREMENT вашей таблицы.