Здравствуйте, _ABC_, Вы писали:
_AB>Linq несет определенные накладные расходы, никто не спорит. При действительно серьезной нагрузке это может стать узким местом. Но при этом
_AB>он обычно (подчеркну — обычно) генерирует код, который оптимальнее того, что написал бы (или склеил) среднестатистический разработчик, который
_AB>полагает, что знает SQL. К тому же, он это делает безопасно и корректно. Вы не справились в приведенных Вами примерах даже со вторым. Про первое
_AB>говорить пока что рано, хотя и там потенциально все печально, т.к. озвученный принцип построен на подзапросах и из запроса тащатся лишние данные,
_AB>что обойдется в потенциале существенно дороже обхода дерева выражений.
Более того, обычно оптимизатор на стороне DBMS достаточно консервативен. Он не занимается глобальными семантическими оптимизациями типа выброса незначащих джойнов или приведения подзапросов.
Поэтому подготовка хорошего SQL — это the must для приложения, претендующего на производительность. Говноинструменты могут сколько угодно гордиться тем, что у них тратится на 960 меньше тактов для генерации SQL строки.
А сервер от лишнего mytable t1 join mytable t2 on t1.id = t2.id поднимет с винта лишний терабайт данных. И на синтетике, возвращающей 0 строк, говноинструмент покажет выигрыш, а с реальными данными тупо ляжет навзничь.