Есть форма регистрации с некоторым числом полей. Есть обработчик, в котором что-то типа:
$result = $mysqli->query("SELECT * FROM ..... WHERE ...... ");
$row = mysqli_fetch_array($result);
//Дальше идут проверки на валидность и есть ли пользователь в БД.
//Если пользователя нет в БД:
$result_query_insert = $mysqli->query("INSERT INTO..........VALUES....");
И даже если пользователь не прошел проверки, в БД увеличивается auto_increment поля ID(primary,AI).
Как избежать этого? Чтобы AI увеличивался только для новых(прошедших проверки) пользователей.
Разрывы в значениях автоинкремента БУДУТ. Более того - их практически не может НЕ БЫТЬ в условиях многопоточного доступа. Но...
Автоинкрементное поле, оно же синтетический ключ - это элемент, который Ваас в принципе не должен волновать. Более того - в нормальных условиях Вы вообще не должны знать, тем более использовать смыслово, его значение. Автоинкрементный первичный индекс - ОН НЕ ДЛЯ ВАС!!! Его назначение - обеспечение исходных данных для организации связи таблиц и (это главное!) для работы подсистемы сервера БД по контролю целостности и непротиворечивости информации.
Никогда не следует на одну сущность возлагать две функции - они обязательно войдут в противоречие. Вам нужна непрерывная нумерация? заведите для неё отдельное поле, и рас(пере)считывайте его значение для каждой новой (обновляемой) записи. И будет Вам полное благолепие и красота - автоинкремент для связи, отдельное поле для нумерации, и ни одного Труффальдино. И будет Ваша система жить долго и счастливо.
Те же соображения, кстати, следует принимать во внимание, если вдруг возникло желание пересчитать значение автоинкрементного поля или выполнить ручное присвоение, дабы "залатать дырки". Немедленно выбросите эти идеи из головы! Присвоенное значение автоинкремента однозначно идентифицирует запись - это уже должно было стать понятным. Но есть несколько неожиданный вопрос - а каков срок жизни этого соответствия? И не менее неожиданный на него ответ - в течение всего срока жизни таблицы(!!!). Да-да, именно таблицы, а не записи! То есть запись может быть давным-давно удалена, значение вроде свободно - но связь всё ещё сохраняется! И использовать его - нельзя! А если хочется - см. выше, плюс ещё одно поле.
Да, есть те (и таких немало!), кому на всё вышенаписанное можно начхать. Но они прекрасно понимают всё это, и, трезво сравнив профиты и грабли, обоснованно решили, что первое перевешивает, а второе нейтрализовано соответствующими мероприятиями. Или, наоборот, они не подозревают о рассказанном выше - ну что ж, кому-то приходится учиться и на своих, а не чужих, ошибках.
Это ошибка логики приложения. Если проверка не пройдена запрос INSERT выполнятся не должен.
Апостиль в Лос-Анджелесе без лишних нервов и бумажной волокиты
Основные этапы разработки сайта для стоматологической клиники
Продвижение своими сайтами как стратегия роста и независимости