Hibernate - первая вставка Sql занимает много времени
Я пытаюсь вставить запись в БД с помощью 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, COLUMN6, COLUMN7, COLUMN13, COLUMN109, COLUMN8, COLUMN109, COLUMN8, COLUMN109, COLUMN8, COLUMN109, COLUMN13) (?,?,?,?,?,?,?,?,?,?,?,?,?,?)
Тот же самый sql, если я выполняю из любого другого инструмента (разработчик Oracle SQL), это занимает около 20 миллисекунд.
Последующие вставки sql, выполняемые спящим режимом, занимают всего около 15-20 миллисекунд.
Возникает вопрос, почему первая вставка sql в Hibernate занимает так много времени, почти в 10 раз по сравнению с последующими вставками sql?
Ответы 1
Чтобы ответить на этот вопрос, вам нужно узнать:
- как запрос обрабатывается на стороне базы данных - см .: Руководство по настройке Oracle Database - обработка SQL
- как запрос кешируется на стороне клиента - см .: Руководство разработчика Oracle Database JDBC - Кэширование инструкций и наборов результатов
Вкратце: когда SQL-запрос поступает от клиента к базе данных в первый раз, база данных выполняет некоторые дополнительные шаги перед выполнением этого оператора (см. Первую ссылку). После этого самого первого раза план sql для этого оператора помещается в общий пул (вид кеша), и база данных может пропускать несколько наиболее трудоемких задач (жесткий синтаксический анализ - оптимизация и создание источника строк) для всех последующих запросы для этого конкретного запроса - этот процесс называется "мягким синтаксическим анализом" на диаграмме по приведенной выше ссылке. Если общий пул очищен (например, после перезапуска базы данных), эти шаги необходимо повторить еще раз для первого входящего запроса - и это займет дополнительное время. Оператор удаляется из кеша, когда какая-либо таблица / представление, на которую ссылается запрос, изменяется (например, после команды ALTER TABLE или команды CREATE / DROP INDEX), и база данных снова выполняет жесткий синтаксический анализ после этого, и это занимает еще раз.
На стороне клиента, когда выполняется инструкция в первый раз, она помещается в кеш (см. Вторую ссылку) - и это должно занять некоторое дополнительное время. После этого для всех последующих вызовов оператора запрос извлекается из кеша, и это улучшает производительность. Когда драйвер базы данных закрывается (например, при перезапуске приложения), кеш очищается, и следующий вызов оператора снова должен занять дополнительное время. Вы можете явно отключить кеширование операторов (подробные инструкции см. Во втором разделе), и, скорее всего, вы увидите, что все выполняемые операторы займут больше времени.