Есть ли вред в сбросе автоинкремента?

Скорее всего, вы ничего не получите от этого, и вы можете легко привлечь ваше приложение, перезаписывающие строки, поскольку вы собираетесь сбросить счет для идентификаторов. (Другими словами, в следующий раз вы вставите ряд, он перезаписывает ряд с идентификатором 1 , а затем 2 и т. Д.) Что вы получите от заполнения пробелов ? Если число становится слишком большим, просто измените его на большее число (например, Bigint ).

Редактировать: Я стою исправлена. Это ничего не сделает вообще, что поддерживает мою точку зрения, что вы должны просто изменить тип столбца в более широкий целочисленный тип. Максимально возможное значение для Bigint составляет 2 ^ 64, что составляет более 18 квинтиллионе . Если у вас есть только 100 миллионов строк, что должно быть много для обозримого будущего.

Я согласен с MusicFreak ... максимум для целого числа ( int (10) ) составляет 4 294 967,295 (без знака). Если вам нужно идти еще выше, переключение на Bigint приносит вам до 18 446 744 073 709 551615.

FWIW... Согласно MySQL docs применение

ALTER TABLE tbl AUTO_INCREMENT = 1

, где tbl содержит существующие данные, не должно иметь эффекта:

Изменить значение параметра Счетчик AUTO_INCREMENT, который будет использоваться для новые строки, сделайте так:

ALTER TABLE t2 AUTO_INCREMENT = значение;

Вы не можете сбросить счетчик на a значение меньше или равно любому другому уже использовались. Для MyISAM, если значение меньше или равно максимальное значение в настоящее время в В столбце AUTO_INCREMENT значение равно сброс на максимальный ток плюс один. Для InnoDB, если значение меньше чем текущее максимальное значение в столбец, ошибки не возникает и текущее значение последовательности не изменяется.

Я провел небольшой тест, который подтвердил это для таблицы MyISAM.

Итак, ответы на ваши вопросы следующие: никакого вреда и нет, это не заполнит пробелы. Как говорили другие респонденты: изменение типа данных выглядит наименее болезненным выбором.

Так как вы не можете изменить следующее значение автоматического приращения, у вас есть другие варианты. Переключатель DataType может быть сделан, но мне кажется немного тревожным, так как у вас на самом деле нет много строк. Вам нужно будет убедиться, что ваш код может обрабатывать идентификаторы, которые большими, которые могут или не могут быть для вас.

Вы можете сделать много времени? Если вы есть, есть два варианта, о которых я могу подумать:

1. Дамп / Перезагрузить данные. Вы можете сделать это, чтобы он не сохранил идентификационные номера. Например, вы можете использовать выбор ... в копирования данных, SANS-IDS, на новую таблицу с идентичным DDL. Затем вы бросаете старую таблицу и переименуйте новую таблицу на старое имя. В зависимости от того, сколько данных существует, это может принять заметное о времени (и временное дисковое пространство).

2. Вы можете сделать небольшую программу для выпуска операторов обновления для изменения идентификаторов. Если вы позволите этому запустить медленно, это «дефрагментируют» свои идентификаторы со временем. Тогда вы можете временно остановить вставки (всего в минуту или два), обновите последние идентификаторы, затем перезапустите ее. После обновления последних идентификаторов вы можете изменить значение AUTO_INCREMENT, чтобы быть следующим номером, и ваше отверстие исчезнет. Это не должно вызывать каких-либо реальных простоя (хотя бы на InnoDB), но он может занять некоторое время в зависимости от того, насколько агрессивна ваша программа.

Конечно, оба из них игнорируют ссылочную целостность. Я предполагаю, что это не проблема (операторы журнала, которые не используются как зарубежные ключи, или некоторые такие).

действительно ли это имеет значение, если есть пробелы?

Если вы действительно хотите вернуться и заполнить их, вы всегда можете отключить автоматическое увеличение, и вручную сканировать для следующего доступного идентификатора каждый Время, которое вы хотите вставить ряд - запомнить, чтобы заблокировать таблицу, чтобы избежать гоночных условий, конечно. Но это много работы, чтобы сделать не так много приростов.

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