В целом, если вы используете HQL или Критерии для создания окончательного SQL, вы не увидите большой разницы в производительности в более поздних версиях Hibernate (версия 3.3 и выше).
Чтобы проверить это, вам нужно создать репрезентативный запрос как на HQL, так и с использованием интерфейса Criteria.Затем зарегистрируйте полученный SQL-код из более старых версий Hibernate (возможно, с помощью Maven для быстрого изменения версии).Вы заметите, что при уменьшении версий Hibernate вы увидите изменения в окончательном SQL.
Нет смысла пытаться оптимизировать HQL и критерии в коде, поскольку подавляющее большинство потерянного времени будет находиться в сети.трафик между вашим приложением и базой данных.Конечно, это предполагает, что у вас есть правильно сформированный запрос, который не требует многократного сканирования всей таблицы более ста миллионов строк или чего-то еще.
Цитируемый блог пытается развенчать мифы , поэтому будьте осторожны, чтобы не вывести заголовок из контекста (выделено мое):
9) «Hibernate работает медленно, потому что SQL, сгенерированный интерфейсом Criteria, не согласован» *
Говорят, что Hibernate также может вызвать снижение производительности, если вместо этого все запросы строятся через интерфейс Criteria.прямо в HQL.Аргумент утверждает, что это происходит потому, что каждый раз, когда выполняется код построителя запросов, скажем, в DAO, Hibernate будет генерировать новые псевдонимы для таблиц в запросе.В Oracle это означает, что каждый раз, когда запускается новый запрос на основе критериев, база данных должна создавать план выполнения запроса QEP - поскольку она не может соответствовать SQL, который был задан любому в своем кэше.Создание QEP может занять 30% времени, которое требуется Oracle для ответа на оператор SQL, поэтому для второго и последующих выполнений того же (но для псевдонимов) оператора SQL у Criteria есть встроенная служебная информация, которая делает егоНа 50% медленнее, чем прямой HQL.
Это больше не относится к Hibernate 3.3 и выше. Если это вообще когда-либо было правдой, то это вызывает сомнения, поскольку команда Hibernate, безусловно, будет стремиться создавать оптимальный SQL, где это возможно .Независимые тесты показывают, что тот же запрос генерируется интерфейсом Criteria после повторных вызовов, охватывающих транзакции, что эквивалентно запуску приложения под нагрузкой.В каждом случае запрос оставался идентичным и поэтому мог кэшироваться Oracle.
Однако есть одна грань правды в том, что необходимо создавать запрос каждый раз, используя интерфейс Criteria, тогда как при использованииИменованные запросы, определенные в HQL, позволяют выполнять предкомпиляцию во время запуска приложения.Однако это требует некоторой перспективы.Время, необходимое для создания простого «промежуточного» запроса с использованием интерфейса Criteria, составляет примерно 3 мс на среднем ПК.Встраивание HQL в приложение не является хорошей альтернативой, поскольку оно не приводит к интуитивно понятному механизму обслуживания запросов с различными стратегиями выборки, и поэтому подход, основанный на критериях, считается лучшим из двух.
Таким образом, блог, по сути, указывает на то, что основное отличие заключается в том, что интерфейс Criteria может внести несколько миллисекунд дополнительных накладных расходов на обработку, которых можно избежать с помощью прямого подхода HQL.HQL также немного более лаконичен в своем выражении запроса, который многие найдут привлекательным.
Короче говоря, разница настолько мала, что вам не нужно об этом беспокоиться.