psyh1031) Вариант : делаю два запроса:
1. COUNT (SELECT..WHERE....) - получаю total
2. SELECT..WHERE....LIMIT=50 - получаю 50 результатов

Вполне стандартный подход. Все так делают.

psyh1032) Вариант : выбираю все при помощи hibernate (или чего-то аналогичного) в java List<Results>, беру list.size(), и выбираю 50 первых результатов

В hibernate много такого чего в чем-то аналогичном может и не быть.

psyh103В первом случае меня смущает то, я всегда делаю два запроса подряд к базе (вместо одного)

Ну, если это смущает только вас и не смущает DBA, то, наверное, не страшно.

psyh103Во втором то, что я выгружаю 87300 объектов в оперативную память в JVM (а при этом аналогичный запрос приходит он нескольких сотен пользователей одновременно и для каждого нужно все результаты тянуть в оперативку)

Ну, зачем так сразу. Hibernate может много чего предложить для решения этого вопроса. Например существует такой метод
http://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/Session.html#createFilter-java.lang.Object-java.lang.String-
Если, я правильно понял, то ему можно скормить ленивую коллекцию и потом загружать ее постраничено через Query
Другая сторона вопроса это кэш второго уровня. Не зачем читать все объекты из БД для каждого пользователя. Можно их сформировать из кэша. Правда, тут есть нюанс, в виде того как работает кеш. Он собирает новые объекты из слепка. Поэтому каждый пользователь расходует память. Но это вполне можно оптимизировать, если иметь, например, список id. В общем, есть над чем подумать.

psyh103[b]Правильно ли я понимаю работу памяти во втором случае?

Да, но есть варианты.

psyh103Какой вариант "дешевле" и принято использовать, как наиболее рациональный?

Два запроса к БД, скорее всего, будут рациональнее. Но если между сервером и БД воткнуть толковый кэш, то будет "еще более рационально". Поэтому я за Hibernate + Paging любым удобным для вас способом (JPQL, HQL, Criteria API, Lazy Collection)

Partisan MВсе, кто не понимает, что делает. Вполне стандартная ошибка.

Ой, да.

Partisan M- иметь в таблице поле, подходящее для счётчика записей и делать в цикле выбор диапазонов по этому счётчику. Например, в Oracle уже есть такое поле ROWID.

Ага. Еще один ID, который нужно генерировать правильным образом. Я понимаю, что кроме Oracle других RDBMS не существует. Но все же, у ТС может и MySQL оказаться.

Partisan M- в процедурном SQL соответствующей СУБД делать в цикле выборку с использованием курсора. Метод довольно универсальный, поскольку в популярных СУБД курсоры есть. Хотя синтакис зависит от СУБД.

Курсор. На трехзвенке. Опять, с условием, что у нас только Oracle?

Partisan MНеправильно использование OFFSET... LIMIT и Hibernate. Способ с OFFSET...LIMIT неэффективен, потому что будут считываться все записи с начала и уже потом из них выбираться нужные. Способ с Hibernate неправильгный потому, что в нём Hibernate испольхуется не по назначению. Следовательно, вряд ли можно надеяться на особую эффективность.
Возможно. Если автор им особо и не пользуеются и изучать не хочет, то и приплетать ORM, наверное, смысла нет.