Что является лучшей производительностью в пользовательском запросе hibernate или HQL

В коде на стороне сервера, как правило, для лучшей производительности нам не следует использовать "select * from table", а мы должны запросить нужный столбец в соответствии с потребностью (Select name, add from employee). Это я прочитал в руководстве по производительности базы данных статья.

Теперь у меня есть quetion with hibernate, я читаю, что лучше использовать session.load(id) в спящем режиме для восстановления записи на основе первичного ключа. Это будет возвращать весь столбец, связанный с сущностью для данного "id" (запись из таблицы).

Теперь это не противоречит основному руководству по производительности базы данных. которая лучше работает с hibernate native sql query или спящим языком запросов?

Позвольте мне знать ваши ценные данные, поскольку я пытаюсь настроить мой код для лучшей производительности.

ОТВЕТЫ

Ответ 1

Ты испортил некоторые части. Вы можете выбрать только определенные столбцы с помощью HQL, например, вы можете использовать select column from table в HQL.

Native SQL не обязательно быстрее, чем HQL. Наконец, HQL также переведен в SQL (вы можете увидеть сгенерированный оператор при запуске приложения с свойством show_sql, установленным в true). В некоторых случаях Hibernate не может генерировать наиболее эффективные операторы, поэтому собственный SQL может быть быстрее - но с собственным SQL ваше приложение теряет переносимость из одной базы данных в другую, поэтому обычно лучше настроить отображение hibernate и HQL для создания более эффективных операторов SQL. С другой стороны, с родным SQL вам не хватает кэша Hibernate - как следствие, в некоторых случаях родной SQL может быть медленнее, чем HQL.

Когда вы используете session.load(class, id), а строка еще не находится в кеше, нагрузка также генерирует select * from classTable, поэтому скорость аналогична скорости HQL from. (Но когда объект уже находится в кеше, возможно, load быстрее.)

Я не согласен с вашими рекомендациями по эффективности: в большинстве случаев для производительности это не имеет значения, если вы загружаете все столбцы или только нужные столбцы. При доступе к базе данных время при поиске строки теряется, а не при передаче данных в приложение. Когда вы читаете только необходимые столбцы, у него есть следующие недостатки:

  • Если вам нужны столбцы, которые вы еще не загрузили, у вас больше проблем с изменением вашего приложения (или вам нужно снова загрузить строку, что означает низкую производительность).
  • Это дает плохой дизайн вашему приложению (Hibernate предпочитает одну таблицу - один класс)
  • Это не работает с кэшем Hibernate.

(Мысль, если в вашем приложении есть столбцы, которые вам никогда не нужны, или для столбцов, которые будут добавлены после завершения вашего приложения, тогда вы просто не помещаете их в свой класс и ваше сопоставление, и они никогда не будут быть загружен, и ваш дизайн приложения по-прежнему хорош. Hibernate не генерирует операторы select * from table, он всегда генерирует select col1, col2, ... from table.)

Есть одно исключение: если вы загружаете огромное количество данных - тысячи строк - тогда загрузка только необходимых столбцов может быть значительно быстрее.

Ответ 2

Сущностные запросы (например, JPQL, HQL, Criteria API) снова обрабатываются обратно на SQL-запросы, поэтому очевидно, что выполнение нативного SQL-запроса будет быстрее, чем выполнение сущностного запроса.

Однако, если вы установите правильный размер кэша плана запросов, вы сможете ускорить запросы сущностей, чтобы они выполнялись так же быстро, как и запросы SQL.

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