Форум MySQL

AUTO INCREMENT добавляет записи в таблицу в порядке возрастания - 1, 2, 3, 4, 5, ... 124, 125 ... Потом скажем в процессе обработки данных в таблице были удалены записи 1, 2, 3 ... Как сделать, так что бы не изобретать велосипед, что бы новая запись была в доступную после удаления ячейку 1, 2, 3 а не продолжало по возрастанию добавлять 126, 127, 128 ...

вы не поверите, но это самая грубейшая ошибка начинающих изучать MySQL.
id - это не порядковый номер, это идентификатор строки обеспечивающий её уникальность
___
воспользуйтесь поиском, тем подобных вашей миллиарды

Не нужно для "красоты" заполнять пропуски... есть способы, это реализовать, хотя СУБД будет сопротивляться из-за всех сил, но лучше все оставить как есть. Смотрите, есть статья, на неё имеется масса ссылок с других сайтов. Вам нужно её удалить, таким образом, чтобы переход по существующим ссылкам приводил к странице с кодом 404. При существующем механизме так и будет, если вы удаленные статьи будете заполнять другими записями, у вас вместо 404 будет новая статья. В результате у вас будет потеря целостности, вы запутаете посетителей и поисковых роботов (а они на это реагируют плохо). Это самый простой пример, возникающих проблем, на самом деле их будет очень много, заковыристых и у вас не будет никаких инструментов для их разрешения. Пропуски в нумерации - это тоже очень важная информация, которую лучше сохранять.

Согласен, но ведь кроме статей могут быть таблицы например логов, которые скажем каждый день очищаются старые более 7 дней записи, при этом если нагрузка достаточно приличная то таких логов в день сотни тысяч (мой случай), за считанные месяцы дойдет до предела 4294967295 INTEGER, потребуется BIGINT для id или же сбросить всю таблицу на 0. Вот и думал может быть есть какие то методы уже встроенные в MySQL для устатовки уникальных id. Думал в качестве идентификатора отказаться от auto increment функции MySQL для id и использовать PHP функцию uniqid() на основе microtime(), для записи ключевого значения таблицы, но будет ли это правильно работать, не могут ли возникнуть 2 одинаковых uniqid() при высокой нагрузке? Или вообще не парится и использовать BIGINT и периодически делать TRUNCATE?

>за считанные месяцы дойдет до предела 4294967295 INTEGER, потребуется BIGINT для id или же сбросить всю таблицу на 0.
У вас сервер взвоет раньше - придется таблицу пилить, в BIGINT ничего страшного нет, изменить INT на BIGINT можно единственным ALTER-запросом. Под логи лучше сразу использовать BIGINT (SERIAL).

>Думал в качестве идентификатора отказаться от auto increment функции MySQL для id и использовать PHP функцию uniqid() на
>основе microtime(), для записи ключевого значения таблицы, но будет ли это правильно работать, не могут ли возникнуть 2
>одинаковых uniqid() при высокой нагрузке? Или вообще не парится и использовать BIGINT и периодически делать TRUNCATE?
Будет очень медленно, что критично при записи в лог-таблицы, кроме того, вам будет действительно сложно гарантировать уникальность, вернее уникальность можно будет обеспечить, сложно будет не терять при этом записи. Используйте BIGINT - вам его хватит, если вам его не хватит, значит у вас очень большой проект и у вас есть деньги на сотню другую серверов + у вас такое количество проблем, что BIGINT среди них - приятная мелочь. Даже если хотите использовать UNIQID, используйте MySQL, а не PHP-функцию.

Просто сделайте такое упражнение: подсчитайте, какой объем занимает переполненная таблица с единственным ключом BIGINT из расчета, что 64-битное число занимает 8 байт. Заранее, принимаю ваш довод, что старые журнальные записи будут удаляться. Если у вас остаются сомнения, подсчитайте, сколько сотен тысяч лет пройдет до исчерпания такой таблицы, если каждую секунду в таблицу добавляется 1 000 000 записей. BIGINT - это очень много, это не в два раза больше, чем, INT, хотя места занимает ровно в два раза больше чем INT.

> если нагрузка достаточно приличная то таких логов в день сотни тысяч (мой случай),
> за считанные месяцы дойдет до предела 4294967295 INTEGER
Воспользуйтесь калькулятором. Даже при миллионе таких записей в день, на переполнение уйдет почти 12 лет! Я уж молчу про BIGINT.