Здравствуйте, zelenprog, Вы писали:

G>>...план SQL-запроса оптимизируется по костам БД-инженером...
Z>Не понял что такое "костам"?

"Кост" — это "стоимость" каждого этапа выполнения SQL-запроса (в условных попугаях, отражающих перформанс БД — скорость и размер памяти).
Например, если в запросе есть выборка из таблицы по полю (фильтр), которое не имеет индекса, то "стоимость" такой операции высокая, т.к. движок БД вынужден делать полный перебор O(n) таблицы для применения данного фильтра.
Навешивание индекса на поле снижает "кост" и по скорости, т.к. теперь движок делает не полный перебор O(n), а частичный, например, по B-tree или по хэшу.
Вручную анализировать сложный SQL-запрос таким образом тяжело, поэтому любой уважающий себя БД-движок имеет команду explain, которая выводит кост-план конкретного запроса и позволяет сразу видеть узкие места и подтюнить БД. Эту работу обычно выполняет БД-инженер.
Выполнять поэтапную фильтрацию на стороне бэкэнда — так в реляционных БД не делают, это очень ресурсоёмко, обычно fleunt-цепока вызовов Criteria API на стороне бэка (DAO-слой ) формирует сложный SQL-запрос, который улетает в БД и обратно возвращается уже отфильтрованное.