ответ был в самом первом посте.

только вместо селескт трали-вали

инсерт инту табле селект-траливали

тоесть выборка и тутже вставка. паралельный изза уникальности поля(оно должно быть) уже выдаст ошибку, и тогда да повторно вставить.

насчёт того что один запрос будет выполняться час... ну формально, если бросать монетку (решка - выполниться первее другого, орёл - после) то шанс есть что 10000 раз выпадет решка. но с таким шансом и даже большим, у вас куча багов и ошибок на проекте.

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

========
зы я бы не так делал, и начал бы с абсурдности поиска минимального айди.

абсурдности.
1)мы нашли минимальный 10, потенциальная проблема, что другой запрос тоже найдёт минимальный 10, вместо 11 - тогда возникает вопрос, разве не было бы решением если второй искал бы сразу не минимальное а 11. это явно автора устраивает, соответсвенно вопрос - так зачем мы исчём именно минимальное, а не просто любое значение которого нету?

2)вариант заканчивающегося за месяц айди, на фоне ГРУППЫ номеров(даже не номера) и максимальным значением 64битного числа представляеться абсурдом, особенно если учесть что можно брать ГУИД или подобное...128 битные значения, можно 256 битные значения.
не надо переживать изза возростающей нагрузки- костыли и руки из сопы куда более нагрузят базу.

3) сам запрос...он довольно таки тяжёллый. он вообще сколько времени на этой таблице выполняеться

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

(что-то мне кажеться, что это фанстическое предположение автора, что у него закончаться айди)

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

ТАК ЧТО автору надо менять изначальный подход с этими минимальными айди.

mini.weblabalex564657498765453зы я бы не так делал, и начал бы с абсурдности поиска минимального айди.

абсурдности.
1)мы нашли минимальный 10, потенциальная проблема, что другой запрос тоже найдёт минимальный 10, вместо 11 - тогда возникает вопрос, разве не было бы решением если второй искал бы сразу не минимальное а 11. это явно автора устраивает, соответсвенно вопрос - так зачем мы исчём именно минимальное, а не просто любое значение которого нету?

а я бы посмотрела
a) на код где вы находите 11-й отсутствующий ID
б) на код где вы находите произвольный отсутствующий ID
с) давайте предполагать, что автор использовал SMALLINT для ID
=)

с)и что, религия запрещает перейти на другой тип?
б)как два пальца об асфальт.даже без джоина,...сдесь на форуме уже были даже готовые примеры через переменные
а)вы не поняли мысли.... зачем акцент на минимальном айди, и как пример, второй процес сразу взял себе 11, а первый 10 потом- они искали не минимальный...но суммарный эффект как будто бы минимальный - явно не противоречит ТС, а следовательно - требования а минимальности не обязательное условия для решения задачи. ... это догматично показал на пальцах, что минимальность сдесь не нужна(ну либо ТС плохо описал что у него там проиходит)

hatedО! Оживление =)

В общем, не буду привязываться к цитатам отвечу в общем.
Да скорее всего я и погорячился - может не месяц, может даже не два и не год. Но!!! Это еще хуже, сейчас я знаю об этом узком месте и пытаюсь его оптимизировать, но забей я на это - в один прекрасный момент получаю баг, потери времени на исправление, потере на возмещение убытков простоя и т.д. Сейчас у нас 8 едентичных баз(разные города), кто знает сколько их будет через год-два... И уж тем более потом угадай в какой базе кончатся айдишники... Зачем эта бомба замедленного действия если вполне можно обойтись и без неё?...

Не отрицаю существование способов реализации более правильных и менее косячных и ресурсоемких. Но!!! Эта функция работает с 2011го года и косяки выявились только сейчас(и то редкие и не значительные), по нагрузке/времени работы нареканий нет... По этому смысла менять принцип работы и рисковать появлениями других багов(в случае если что-то забыл/не учел), лично я не вижу...

Итого:
От блокировок решил отказаться - побоялся и сделал как описал выше - перевел в Inno и делаю рекурсию если не произошла вставка.
_{function newPhonesGroup()
{
$minId = mysql_result(mysql_query("SELECT MIN(NULLIF(R1.groupid + 1, R2.groupid)) as mid FROM (SELECT groupid FROM phonesgroup UNION SELECT 0) R1 LEFT OUTER JOIN phonesgroup R2 ON R2.groupid = (R1.groupid + 1) OR R2.groupid IS NULL"),0,'mid');
if (!$minId || !mysql_query("insert into phonesgroup(groupid,cdate)values($minId,'".date('Y-m-d [H:i:s]')."')"))
{
sleep(1);
return newPhonesGroup();
}
return $minId;
}}
Пока косяков не выявлено - как будут - обещаю Вас поставить в известность и быть более внимательным к вашим советам! =)

дык что косяков пока не было?! Будут! пышли студент.