Разбиение на страницы в гибернации с использованием HQL

Проблема с разбивкой на страницы в спящем режиме

I есть проблема, связанная с разбивкой на страницы в Hibernate, и в некоторой степени это было объяснено в

Mysql Pagination Optimization

Использование ScrollableResults Hibernate для медленного чтения 90 миллионов записей

Hibernate - разбиение на страницы HQL

Проблемы с разбиением на страницы и Сортировка

Пагинация строк в спящем режиме

Подробности

Запрос HQL из приложения:

Query q = session.createQuery("from RequestDao r order by r.id desc");
            q.setFirstResult(0);
            q.setMaxResults(50);

Запрос возвращает 3 миллиона записей, и для разбивки на страницы мы устанавливаем только 50 из этих записей, страница разбивки на страницы выполняется очень медленно, потому что при каждом обновлении мы вызывая запрос, который получает 3 миллиона записей, и из них мы устанавливаем только 50 записей.

Мой главный вопрос:

Всегда ли HQL обращается к базе данных или же он обращается к сеансу или памяти для поиска данных, и если он каждый раз обращается к базе данных и получает набор результатов, то это очень правильно с точки зрения производительности Каковы были бы лучшие решения для его улучшения?

Используя HQL в спящем режиме, можно ли запросить базу данных и получить сначала только 50 записей, а затем получить другие записи по требованию пользователя.Эта проблема действительно мешает работе приложения, поэтому как лучше всего решить эту проблему?

HQL-запрос, созданный в журналах

from com.delta.dao.RequestDao r order by r.id desc

Hibernate Generated Query

select
    getrequest0_.ID as ID24_,
    getrequest0_.TIME as START3_24_,
    getrequest0_.STAT as STATUS24_,
    getrequest0_.SUM as SUMMARY24_,
    getrequest0_.OUTNAME as OUTPUT7_24_,
    getrequest0_.INPNAME as INPUT8_24_,
    getrequest0_.REQUEST_DATE as requestT9_24_,
    getrequest0_.PARENT_ID as PARENT10_24_,
    getrequest0_.INTER_TYPE as INTERPO60_24_,
    getrequest0_.OPEN_INT as OPEN61_24_,
    getrequest0_.SOURCE_TYPE as SOURCE62_24_,
    getrequest0_.TARGET_TYPE as TARGET20_24_,
    getrequest0_.SOURCE as SOURCE14_24_,
    getrequest0_.COPY_DATA as COPY16_24_,
    getrequest0_.CURVE as GENERATE63_24_,
    getrequest0_.TITLE as TITLE24_,
    getrequest0_.TIME_ID as TIMESERIES12_24_,
    getrequest0_.TASK_NAME as TASK51_24_ 
from
    REQUEST getrequest0_ 
where
    getrequest0_.KIND='csv' 
order by
    getrequest0_.ID desc

Вот Explain Plan для запроса :

 | id | select_type | table        | type | possible_keys  | key        | key_len | ref          |  rows    | filtered | Extra       | 
 |  1 | SIMPLE      | getrequest0_ | ref  | TR_KIND_ID     | TR_KIND_ID | 6       | const        | 1703018  |   100.00 | Using where |

Дополнительная информация: Время выполнения запроса с предложением order by и без него для ограничения на 50 записей

Если я выполняю запрос с предложением order , то запрос занимает 0,0012 с с параметром LIMIT 50 и без условия заказа , один и тот же запрос занимает 0,0032 секунды с таким же LIMIT 50 .

Также как мы можем узнать, если:

1. Определенный запрос HQL попадает в базу данных, а не в кеш или не получает информацию из сеанса?
2. Верно ли, что запрос HQL всегда отправляется и попадает в базу данных, чтобы получить результат, а критерии будут пойти и нажать сеанс или кеш и получить от него результаты?

3. Также в моем нижеупомянутом запросе:

    a) Query q = session.createQuery ("from RequestDao r order by r.id desc");
   б) q.setFirstResult (0);
   в) q.setMaxResults (50);
   

в a, правда ли, что мы получаем результат из базы данных и сохраняем его в памяти, или где, если нет, и в настоящее время у нас есть 3 миллиона результатов в наборе результатов, а затем в b и c мы устанавливаем значение смещения и ограничиваем и т. Д. На странице мы увидим только 50 результатов, поэтому теперь, где осталось 3 миллиона записей, и при нашем втором вызове этого запроса мы снова идем и нажимаем базу данных, получаем 3 миллиона записей и помещаем их в память, а затем на c снова мы устанавливаем 50 записей и продолжай.

Эта проблема мне непонятна, и я был бы очень признателен, если бы кто-нибудь мог дать четкое и подробное объяснение того, как это работает, и какое было бы лучшее решение для этой проблемы.

Обновление

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

Я делаю несколько вложенных запросов гибернации к базе данных и получаю результаты, что было бы оптимальным решением этой проблемы?