Hibernate - Первая вставка Sql занимает много времени

Question

Я пытаюсь вставить запись в БД с помощью Hibernate.Данные сохраняются в нескольких таблицах в БД.Что касается спящего режима, у меня есть родительский класс Entity с сопоставлением один-к-одному и один-ко-многим другим классам Entity.В режиме отладки я мог видеть, что операция сохранения приводит к нескольким вставкам SQL.Первая вставка sql занимает много времени, примерно 300 миллисекунд.Обратите внимание: сюда не входит время, необходимое для инициализации сеанса, получения соединения JDBC и т. Д. 10: 46: 24.132 [main] DEBUG org.hibernate.SQL - вставьте в MY_SCHEMA_NAME.PARENT_ENTITY (COLUMN1, COLUMN2, COLUMN3, COLUMN4, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COLUMN5, COL., COLUMN7, COLUMN8, COLUMN9, COLUMN10, COLUMN11, COLUMN12, COLUMN13, COLUMN14) значения (?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Тот же sql, если я выполняю из любого другого инструмента (разработчика Oracle SQL), это занимает около 20 миллисекунд.

Последующие вставки sql, выполняемые hibernate, занимают всего около 15-20 миллисекунд.

Вопрос в том, почему первая вставка SQL в Hibernate занимает так много времени, почти в 10 раз по сравнению с последующими вставками SQL?

Answer 1

Чтобы ответить на этот вопрос, вам необходимо узнать:

• как обрабатывается запрос на стороне базы данных - см .: Руководство по настройке Oracle Database - обработка SQL
• способ кэширования запроса на стороне клиента - см .: Руководство разработчика JDBC для базы данных Oracle - Кэширование операторов и наборов результатов

---

Вкратце: когда запрос SQLприходя от клиента к базе данных в первый раз , затем база данных выполняет некоторые дополнительные шаги перед выполнением этого оператора (см. первую ссылку).После этого самого первого раза план sql для этого оператора помещается в общий пул (вид кэша), и база данных может пропустить несколько наиболее трудоемких задач (жесткий анализ - оптимизация и генерация источника строк) для всех последующихзапросы для этого конкретного запроса - этот процесс называется «мягким разбором» на диаграмме по приведенной выше ссылке.
Если общий пул очищается (например, после перезапуска базы данных), эти шаги необходимо повторить снова для первого входящегозапрос - и это занимает дополнительное время.
Оператор удаляется из кэша, когда изменяется какая-либо таблица / представление, на которое ссылается запрос (например, после команды ALTER TABLE или команды CREATE / DROP INDEX), и база данныхпосле этого снова выполняется жесткий анализ, и это снова занимает дополнительное время.

---

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