Упряжка автоинкрементов

Вам случалось иметь таблицу с такой кучей записей, что довольно трудно понимать, что в ней происходит? Если да, то вы поймёте, почему в одном из проектов по ходу необходимого рефакторинга было решено разделить эту таблицу на четыре более мелких. Рефакторинг, как ни странно, прошёл на ура: бранч примёрджился без конфликтов, скрипт для миграции базы тоже вполне неплохо отрабатывал на кошках, то есть на копиях рабочей базы, тесты работали как ни в чём не бывало.

Что ж, сайт закрыт, база обновилась, прошёл скрипт миграции. Сайт запущен и пашет вроде бы даже стабильно. Через день началось. Пользователи перестали регистрироваться, регистрация падала с ошибкой внешнего ключа в одной из получившейся при разделении таблиц. Заказчик в бешенстве, рвёт и мечет, дёргает всех, начиная с разработчика (он прикреплён к поддержке и развитию проекта) и заканчивая директором компании. Директор добавляет своей суеты. Тестировщик на песочнице с рабочей базой повторить баг не может — у него всё пашет на ура.

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

Человек, который разделял таблицу, создал две другие по образу и подобию первой: он поставил в них автоинкремент на первичный ключ. При регистрации пользователя создавалась основная запись, значение автоинкремента увеличивалось, проходили дальнейшие операции. По дороге что-то не срасталось, и транзакция откатывалась, но значение автоинкремента в основной таблице оставалось увеличенным. При следующей попытке регистрация уже не могла пройти никак. Пока «упряжка автоинкрементов» таблиц шла вровень, всё работало. Как только произошла одна ошибка при регистрации, главная таблица вырвалась вперёд.

А мораль такова: как бы вы ни были загружены, обязательно проверяйте миграционные скрипты своих сотрудников!