Prepared statement Из той ветки я понял, что подготовленный запрос выполняется медленнее, если он единственный.
А если сравнить выполнение 1000 раз запроса обычного и 1000 раз запроса предварительно подготовленного (1 подготовка и 1000 выполнений)
Если и на многократном исполнении подготовленный запрос проигрывает, то я вообще в шоке от этой СУБД :)
(Но это уже вариации ПО - не будем спорить - делайте, как быстрее)
Подзапрос в запросе. Подзапрос там "легкий" (exists) - СУБД не будет считать сикоко там записей нашлось, ни, тем паче, выдавать их клиенту.
Да и наш подзапрос ложится в Ваш индекс - вообще мелочи
insert into select Поддерживает? Замечательно! "нельзя использовать ту же таблицу, куда производится вставка." – а мы так и не делаем.
Посмотрите на свой код.
1. Формирование списка IN в foreach - это страшно. Вот где точно тормозить должно. Если IN и используете - стремитесь к его минимальному наполнению.
2. Сперва Вы вытаскиваете (про страшность метода сказано в п.1) на клиента список существующих отелей.
Для этого заставляете СУБД просмотреть ВЕСЬ ваш список (в IN его запихнув)
3. Потом в "неинтересном коде" Вы фильтруете "вставлять/не всталять" - опять просматриваете ВЕСЬ список.
4. Потом Вы еще раз выбираете вставленные отели … я так понимаю, что это такой же страшный IN ПОЧТИ ВЕСЬ список - часть отсеялась в п.3
Частенько встречается слово ВЕСЬ. И данные в/из СУБД гоняются многократно.
Пункт 4 убирается просто. ID записи нужно вставлять вместе с данными … другими словами его надоть узнать ДО вставки. Для этого используются последовательности (SEQUENCE) или их имитация (в гугле полно по этому поводу
http://sqlinfo.ru/forum/viewtopic.php?id=813).
В данном случае можно по другом:
Вставили одну запись;
LAST_INSERT_ID() – узнали ID и куда надо его и ставим; (используя мой запрос .. нужно контролировать, изменилось ли значение, ибо там вставка происходит не всегда)