Есть таблица с записями, упрощенно такая:
id (primary, autoincrement)
group_id (int)
data

Нужно группировать записи по полю group_id. То есть, если при вставке group_id не указан, брать максимальное его значение и увеличивать на единицу. Это будет означать создание новой группы.
Все кажется нормальным, кроме возможной проблемы с паралельными запросами. Т.е. если два запроса попытаются сделать выборку максимального значения + вставку, то возможно дублирование group_id для не связанных записей, что недопустимо. Даже если использовать транзакцию, где соединить выборку максимального значения group_id и вставку записи с group_id+1, то прийдется блокировать часть строк, что при паралельных транзакциях вернет ошибку для второй транхакции. А этого нужно июеждать.

Очевидный вариант с введением дополнительной таблицы не желателен, так как таблиц такого плана в БД очень много и не хотелось бы захламлять ее кучей таблиц с одними только primary key, да и выборку предпочтительнее делать из одной. Надеюсь, я понятно все объяснил.

Используется MySQL InnoDB, но теоретически база можен быть перенесена в другую СУБД.

авторА по какому принципу происходит вставка полей с одинаковым group_id? Т.е. откуда происходит информация о том, что какие-то записи от носятся к одной группе?
Эта система для хранения истории изменений записей. То есть group_id - это одна запись, для которой есть несколько версий из которых только одна актуальная.
Когда добавляется новая запись - добавляется строка с новым group_id, когда запись изменяется - добавляется строка с
существующим group_id.

авторВо-первых, зачем "куча"?
Будет применено для многих таблиц, не считал точно сколько, но не меньше 10.

авторВо-вторых, это же одно удовольствие использовать очевидный вариант:) Почему "захламлять" БД "записями" можно, а "таблицами" нельзя?
Да вообщем-то не хочется захламлять не записями не таблицами :) А еще очень не хочется это все потом переделывать, если всплывет более красивое решение :)

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

БредятинаОпять Вы про каких-то "много таблиц":) Я же говорю, что таблица может быть одна. Еще раз: Вам принципиально, будет у Вас group_id в конкретной "таблице с записями" 1,2,3 или 1,3,6?
Это, конечно чуть быстрее, чем определять максимальное значение group_id, но в целом не решает проблему - нужны те же транзакции, блокировки. Хотя, одна лишняя таблица лучше 10-ти, но это не добавляет понятности. С третьей таблицей, где одно поле-ключ с заполнением group_id как-то логичнее и может даже в некоторых случаях будет что туда сунуть дополнительно.

БредятинаБлокировки при извлечении значения "идентификатора группы" все равно будут. В решении с одной таблицей, одним атрибутом и одной записью нет никаких "ключей", что, может быть, повысит производительность.
Вставка с автоинкрементом все-равно будет быстрее чем транзакция на select и udate с блокировкой, пусть даже в очень маленькой таблице. Какие-то блокировки есть, конечно, и на автоинкремент, но мне кажется, что они значительно более оптимизированы, чем такие транзакции и все-таки позволяют выполнять параллельные insert-запросы.



В общем, я кажется уже принял решение, спасибо всем за ответы и разъяснения.