MySQL: получить младший свободный ID в прорежённой базе

всё ужасно..
чего боишься-то? что номера кончатся?
закройся на техобслуживание, убери «дырки» в id любым из ужасных методов, не забыв переустановить autoincrement counter и всё. а код, который в продакшене работает - не трогай. пусть там дальше будет auto_increment
http://lists.mysql.com/mysql/198896

Старые ID кончились чтоли ?

Сделай таблицу с временными ID, например 1-1000000,
удали из неё записи с ИД которые уже используются
для новых записей выдавай ИД из временной таблицы.

Если бы это был не sql, а какой-нибудь массив структур, то нужно было бы вести список свободных ячеек: когда ячейка освобождается, кладём ее номер в список; когда хотим получить свободную ячейку, изымаем ее номер из списка.

чего боишься-то? что номера кончатся?

Нет. Банальное повторное использование «коротких» ID пользователей :)

закройся на техобслуживание, убери «дырки» в id любым из ужасных методов

Сдвигать имеющиеcя ID нельзя — они в нереляционной форме в ряде мест задействованы.

они в нереляционной форме

этопрекрааасно ;)

Если бы это был не sql, а какой-нибудь массив структур

На Java, когда все ID были в памяти и при залочке потока я эту задачу решал несколькими достаточно эффективными способами когда-то. Но тут — работающая SQL-база :-/

этопрекрааасно ;)

Мир не ограничвается SQL-базой. ID пользователей фигурируют, скажем, в именах файлов, в текстах сообщений, в ссылках в поисковиках и т.п.

сделай поле id 64-битным, и пусть хоть там хоть какое распределение дырок будет, на сто лет ещё хватит.

А нельзя сделать 64-битные id? Это решило бы проблему, так как исчерпать их до второго пришествия ты всё равно не успеешь.

Опередил :)

Иерархические запросы позволяют вычленить отсутствующие элементы. Но на работающей базе с большим количеством строк такое может не взлететь просто потому, что памяти не хватит. =)

Тогда уж лучше сразу делать таблицу из свободных ID (таблицу «дырок») до последней и выдавать из нее? Как только все выбрали - возвращаемся к автоинкременту. Или еще одну итерацию (к тому времени же дырки опять появятся)

Сдвигать имеющиеcя ID нельзя — они в нереляционной форме в ряде мест задействованы.

Т.е. id может не быть в базе, но где то используется? Тогда повторное использование id вызовет некоторые проблемы.

SELECT t1.id+1 FROM tbl AS t1 LEFT JOIN tbl AS t2 ON t1.id+1 = t2.id WHERE t2.id IS NULL ORDER BY t1.id

?

Можно и сразу из «дырок», но тогда каждую проверять. Проще сгенерить
скриптом , потом одним запросом удалить уже используемые. Можно по частям добавлять, чтобы сильно и надолго базу не грузить. Базу можно не блокировать, все равно новые с «большими» номерами идут, а дырки из младших номеров формируются. Остаётся только в клиенте или в базе алгоритм генерации нового ИД поправить. Но вообще изврат :).

Так просто =) И, похоже, это то, что нужно ТС. Только еще min() добавить.

Мир не ограничвается SQL-базой. ID пользователей фигурируют, скажем, в именах файлов, в текстах сообщений, в ссылках в поисковиках и т.п.

все равно же как-то не изящно... ну кроме поисковиков.

Тогда уж лучше сразу делать таблицу из свободных ID

О! А это, в принципе, вариант.

Т.е. id может не быть в базе, но где то используется?

Нет. id удалялись только для объектов, не оставивших нигде следов (обычно это так и не активировавшиеся спамботы, пользователи, так и не начавшие писать и т.п.)

Прекрасно! И работает мгновенно.

все равно же как-то не изящно

Есть альтернативы? :) username — не лучший вариант, так как в теории может меняться. Плюс возникает проблема «минификации» длинных имён, содержащих русский, пробелы и т.п.

У метода есть минус. Никогда не вернет id=1, если его нет. Но в этой задаче это наверное несущественно

Склепай собственный sequence на базе redis.

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

На 56М записях работало минуту. Не то, чтобы в туалет и чайку, но ТС тоже не устроит. А вот на таблицах с 1-1,5М записей работает от 2 до 6 секунд, что может быть вполне приемлемым, если операция редкая. Но тут еще нужно учитывать СУБД и ее настройки, я думаю (тестировал на Oracle 9i с реальными данными).

Ну, я приврал немножко, записей около 2.5 миллионов и машинка слабая, хотя мощнее чем те откуда база принесена. По задаче надо, конечно, смотреть. Как часто , насколько быстро.

А вот на таблицах с 1-1,5М записей работает от 2 до 6 секунд, что может быть вполне приемлемым, если операция редкая

Я выше писал, что речь о базе пользователей. 15 тыс записей — мелочь. И новые записи редко идут.

А там, где миллионы записей, там id обычно итак плотно идут :)

Я выше писал, что речь о базе пользователей. 15 тыс записей — мелочь. И новые записи редко идут.

А зачем, собственно, всё это надо было делать? ID двухбайтовый что ли? 4-байтовый переполниться не мог.

А зачем, собственно, всё это надо было делать?

MySQL: получить младший свободный ID в прорежённой базе (комментарий)

Ну не нравится мне чисто эстетически, когда в базе 15 тыс записей, а ID юзеров по 85 тыс. идут :)

На таких данных мгновенно отрабатывает. Я просто тестировал, как сказал ilovewindows на больших данных.