Проблема автоматического увеличения mySQL: повторяющаяся запись '4294967295' для ключа 1

Question

У меня есть таблица электронных писем.

Последняя запись для идентификатора автоматического приращения - 3780, что является допустимой записью. Любая новая запись, которую я сейчас вставляю, вставляется прямо там.

Тем не менее, в моих журналах есть случайные:

Query FAIL: INSERT INTO mail.messages (timestamp_queue) VALUES (:time);
Array
(
    [0] => 23000
    [1] => 1062
    [2] => Duplicate entry '4294967295' for key 1
)

Каким-то образом автоинкремент подскочил до INT max 4294967295

С какой стати божья зеленая взлетела так высоко? У меня нет вставок с полем id.

Состояние показа для этой таблицы, таблица Auto_increment теперь выглядит следующим образом: 4294967296

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

Josh

Редактировать: Обновить

mysql версия 5.0.45 исправлена ​​красная шляпа

Поскольку я установил идентификатор на BIGINT, последние несколько идентификаторов выглядят так:

3777
3778
3779
3780
4294967295
4294967296
4294967297
4294967298
4294967299
4294967300

Как видите, они являются инкрементными, без пробелов (пока). Совершенно странно.

Answer 1

У меня была такая же проблема с точно таким же номером. Моя проблема была в том, что у меня было поле на int(10), когда я изменил его на bigint(20), это решило мою проблему.

Если у других возникла эта проблема. Сначала проверьте размер своего поля. :)

Answer 2

Мне до сих пор не совсем ясно, что здесь произошло, но я думал, что буду следить.

В моем механизме персистентности у меня был один тип объекта с идентификатором автоинкремента и подкласс с идентификатором GUID.

Очевидно, что они были несовместимы. У меня есть причина преобразовать объект в его родительский и затем сохранить его (в основном подкласс - это ШАБЛОН электронной почты, который имеет дополнительные функциональные возможности, но когда я действительно хочу ОТПРАВИТЬ электронное письмо, я преобразовываю его в родительский объект и сохраняю его в обычная очередь исходящей почты). Глупо, я не осознавал, что форматы идентификаторов были другими. Это привело к попытке вставить запись с длиной строки 36 символов в int. В подготовленном операторе строка преобразуется в «0», и по любой причине это приводит к автоматическому приращению системы к выходу WIG и к максимальному значению поля идентификатора автоматического приращения INT в исходной таблице.

Короче говоря, хорошо, что я вел журналы.

Josh

Answer 3

Обычно это происходит, когда вы случайно вставляете новую запись и предоставляете значение auto_increment.

В большинстве случаев это потому, что у вас есть столбец с похожим именем, и вы создаете опечатку, которая приводит к обновлению значения auto_increment с указанным вами, что составляет 4294967295, если вы указали строку вместо int.

Чтобы решить эту проблему:

• удалить запись со значением PK 4294967295,
• проверьте, какое было максимальное значение приращения, запустив

select max(autoincrementColumNameHere) from tableNameHere

• обновить значение AUTO_INCREMENT, запустив

 ALTER TABLE tableNameHere AUTO_INCREMENT = (maxValue+1)

Answer 4

Это случилось со мной тоже. Проблема глупая.

Если он получает character string, он преобразует его 0 и, если integer, as in my case, where i was trying to insert a mobile no (in india it's 10 digits and starts with 9 like 9123456789 ) into a int`, типа столбец.

Однако предел для signed int составляет 2147483647.

Я пытался преобразовать его в unsigned, но все равно ограничение составляет 4294967295. Таким образом, ошибка «4294967295» что-то, но когда я преобразовал его в bigint, который имеет предел 9223372036854775807 (что больше для 10-значный номер мобильного телефона нет), он начал принимать его.

Ради мобильного телефона нет, я преобразовал его в unsigned, что увеличило его предел до 18446744073709551615.

Answer 5

Это на самом деле только что произошло со мной (до сих пор не знаю, почему). По догадке я сделал:

ALTER TABLE  `{table name here}` AUTO_INCREMENT = {your number here};
FLUSH TABLE `{table name here}`;

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

Answer 6

phpmyadmin просто вы можете изменить последний идентификатор с вкладкой операций этой таблицы

Answer 7

Просто измените его на BIGINT, и вы сможете создать «некоторые» дополнительные новые записи. Пару сотен миллиардов ...;)