Подтвердить что ты не робот

Будет ли MySQL повторно использовать удаленный идентификатор, если применяется Auto Increment

http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html

Этот документ, который я читаю, кажется, говорит что-то вроде:

"В этом случае (когда столбец AUTO_INCREMENT является частью индекса с несколькими столбцами), значения AUTO_INCREMENT используются повторно, если вы удаляете строку с самым большим значением AUTO_INCREMENT в любой группе."

Я действительно не понимаю, что там сказано. Не следует ли автоматически использовать значения, которые следует использовать повторно?

Спасибо заранее...

4b9b3361

Ответ 1

InnoDB сбрасывает поле auto_increment при перезапуске базы данных.

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

Это не произойдет в MyISAM, потому что он кэширует последний инкрементный id.

Ответ 2

Когда у вас есть поле первичного ключа, которое также является auto_increment, независимо от того, сколько строк (или в каком порядке) удалено, идентификаторы, которые больше не существуют, не используются снова, и поле непрерывно увеличивается для каждой строки.

Однако, когда ваш первичный ключ состоит из нескольких полей (E.G. поле auto_increment и другое поле), поле auto_increment используется повторно, и только когда удаленный идентификатор является последним id. Это означает, что если у вас есть значения, такие как 1, 2, 3, 4 и 5, и вы удаляете строку с значением поля 5, следующая строка будет иметь идентификатор 5. Однако, если вы удалите строку с id из 2, это снова не будет использоваться, а следующая строка будет иметь идентификатор 6.

Ответ 3

Как описано с движком InnoDB, последний использованный PK будет использоваться повторно, если строка будет удалена до перезагрузки, поскольку она не кэшируется. Если этот PK является внешним ключом (FK) в другой таблице, могут возникнуть проблемы (FK hell). Вот как я обнаружил проблему, когда маленькая старушка выстрелила до 195 см (!), Поскольку удаленный человек получил дополнительные данные. Для этого нужно либо реализовать "ON DELETE CASCADE" для дочерних таблиц, либо (не мой предпочтительный вариант), чтобы кодировать эту проблему.

Ответ 4

Как указано в answer:

InnoDB сбрасывает поле auto_increment при перезапуске базы данных.

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

и это может привести к проблеме внешнего ключа.

К счастью от MySQL 8.0.0 он будет исправлен. Дополнительная информация:

Ошибка # 199 Статистика автоинкремента Innodb los при перезапуске

WL # 6204: постоянное максимальное значение InnoDB для столбцов autinc

См. BUG # 199 о ошибках MySQL.

В настоящее время InnoDB делает следующее, когда таблица: SELECT MAX (c) FROM t; где c - имя столбца AUTOINC. Этот шаг используется для инициализации следующего значения автоматического значения столбца и с этого момента начинается выделение значений автоиндустрии. InnoDB также делает это когда он выполняет "ALTER TABLE AUTO_INCREMENT = N;".

...

InnoDB должен следить за максимальным значением и при перезапуске сохранять это максимальное значение и начало оттуда.

Ответ 5

Если таблица имеет тип InnoDB, то удаленные идентификаторы повторно используются в определенных сценариях. Вот что я сделал, чтобы проверить это:

  1. Пользователь таблицы имеет столбец идентификатора в качестве первичного ключа с установленным auto_increment

    CREATE TABLE user (id bigint (20) NOT NULL AUTO_INCREMENT, PRIMARY KEY (id),) ENGINE = InnoDB AUTO_INCREMENT = 2108 DEFAULT CHARSET = latin1;

  2. Мой вызов API createUser, создает запись в пользовательской таблице. Допустим, пользователь с id = 1 создан.

  3. Вызовите deleteUser API, который просто удаляет строку из пользовательской таблицы.

  4. Остановите и запустите базу данных

  5. Вызовите createUserAPI еще раз. Создает пользователя с таким же идентификатором (id = 1).

Таким образом, он использует удаленный идентификатор, если сервер перезапущен. Я получил эту проблему, потому что у меня была другая таблица с именем user_rules, которая хранила user_id в столбце, но у нее не было FK-ссылки на пользовательскую таблицу (что было неправильно). Другая проблема заключалась в том, что, когда пользователь удалялся, запись из таблицы user_rules не удалялась, и поскольку у нее не было установлено FK, db также не жаловался. И когда сервер был перезапущен, пользовательские правила были испорчены!

Ответ 6

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