2. Нужно ли включать order by в таких огромных таблицах?
Не зависит от размера базы.
Или у вас есть order by и поведение ожидаемое или у вас нет order by и СУБД имеет полное право на каждый запрос выдавать любые подходящие под фильтр данные в любом порядке.
Запрос выдающий неправильные данные обычно никому не нужен, даже если он и быстрый.
offset для пагинации вообще вещь неуклюжая.
https://use-the-index-luke.com/no-offset
Быстрая пагинация - это передача уникального идентификатора, последнего на просматриваемой странице. Т.е. запрос на выборку следующих 100 записей начиная после такого-то id.
Бонусом консистентное поведение, если, например, что-то из строк предыдущей страницы удалили. Оффсет тупо потеряет строку из выборки и пользователь может не найти то что искал.
3. Ну типа берем сначала вытаскиваем данные с одной таблицы, потом по результату смотрим id, по нему вытаскиваем данные связанные со второй таблицы, затем смотрим новый результат и так же вытаскиваем с третьей. Получается в бд не будет строится огромная временная таблица из трех больших таблиц.
Вы изобрели то что делает джойн. База в общем случае его сделает лучше.
Будет ли огромная временная таблица - смотрите план.
