Какие способы оптимизации LINQ-запросов в C# ты знаешь?

Ну ты смотри, какие умные книжки понаписали про LINQ, а народ всё равно как об стенку горохом. Давай по-человечьи разберём, как не выстрелить себе в ногу, когда ковыряешься с этими запросами.

1. Первое и святое: режь данные сразу, а не потом. Представь, тебе из кучи говна надо только гвозди отобрать. Будешь ты сначала всё говно в тачку грузить, а потом гвозди искать? Нет, ты сразу гвозди отложишь, а остальное нахуй в сторону. Так и тут.

// Делает так: берёт все продукты, для КАЖДОГО высчитывает цену с наценкой, и только потом смотрит, какие больше 100. Тупость.
var slow = products.Select(p => p.Price * 1.2).Where(price => price > 100);

// А вот умный путь: сначала проверяет условие (Price * 1.2 > 100), и только для подходящих высчитывает эту цену. Логично же?
var fast = products.Where(p => (p.Price * 1.2) > 100).Select(p => p.Price * 1.2);

Ставь Where как можно раньше, прямо после источника данных. Перед Select, перед GroupBy, перед OrderBy. Это как фильтр в начале шланга, а не в конце.

2. Не гоняй туда-сюда одно и то же, идиот. Вот классика: получил коллекцию из базы и начал её по десять раз перебирать. Каждый раз, когда ты вызываешь Count(), First(), или просто foreach — это может быть новый поход в базу, если ты не закэшировал результат. Это называется N+1 проблема, и от неё все плачут.

// КАЖДЫЙ вызов ниже — это потенциально новый запрос к базе. Представляешь, сколько времени?
var badQuery = context.Products.Where(p => p.IsActive);
if (badQuery.Any()) { ... }      // Запрос 1
var count = badQuery.Count();    // Запрос 2
var list = badQuery.ToList();    // Запрос 3

// Правильно, по-пацански: сходил в базу ОДИН РАЗ, притащил всё, что нужно, и работаешь с памятью.
var goodData = context.Products.Where(p => p.IsActive).ToList(); // Запрос выполнился тут, 1 раз
if (goodData.Any()) { ... }      // Считаем в памяти
var goodCount = goodData.Count;  // Берём свойство у списка, мгновенно
var first = goodData.First();    // Ищем в памяти

3. Хватит считать всё подряд, чтобы понять, есть ли хоть что-то. Тебе нужно просто узнать, есть ли в коллекции хоть один рыжий кот. Ты что, будешь пересчитывать ВСЕХ котов в городе? Нет, ты увидел первого рыжего и успокоился.

// Ужас: посчитает ВСЕ продукты в категории 5, только чтобы понять, что их больше нуля.
if (products.Count(p => p.CategoryId == 5) > 0) { ... }

// Гениально: найдёт ПЕРВЫЙ подходящий и сразу скажет "да, есть". На этом всё.
if (products.Any(p => p.CategoryId == 5)) { ... }

Запомни: Any() для проверки существования, Count() — только если реально нужно знать количество.

4. Если ищешь что-то в огромном списке много раз — не будь бараном, используй HashSet. Contains на обычном List — это тупой перебор с начала до конца. Если список на миллион записей, а проверяешь ты тысячу раз — это пиздец как долго.

List<int> hugeList = ...; // Допустим, там миллион айдишников
// Плохо. Каждый раз — прогулка по всему списку.
bool foundBad = hugeList.Contains(12345);

// Отлично! Один раз потратил время на построение хэш-таблицы, зато потом поиск за микросекунды.
var speedySet = new HashSet<int>(hugeList);
bool foundGood = speedySet.Contains(12345); // Мгновенно, потому что это не поиск, а почти прямое попадание.

5. Соединяй коллекции с умом, а не вложенными циклами. Когда нужно связать заказы с клиентами, новичок пишет вложенный Where. Получается, для каждого заказа он пробегает по ВСЕМ клиентам. Это как искать свою пару на дискотеке, подходя к каждому человеку и спрашивая "ты моя Маша?".

// Тупой и медленный способ (N * M операций сравнения)
var naive = from order in orders
            from customer in customers
            where order.CustomerId == customer.Id // Сравниваем каждого с каждым
            select new { order, customer };

// Умный способ. Join сделает это эффективно, обычно через хэш-таблицу, примерно за (N + M) операций.
var smart = from order in orders
            join customer in customers on order.CustomerId equals customer.Id
            select new { order, customer };

6. Понимай, когда твой запрос готовится, а когда выполняется. LINQ — ленивая штука. Пока ты не попросишь конкретный результат, он просто запоминает твои инструкции.

• Готовит рецепт (отложенное выполнение): Where, Select, OrderBy. Запрос ещё не пошёл в базу.
• Требует готовое блюдо (немедленное выполнение): ToList(), ToArray(), Count(), First(). Всё, тут запрос выполняется и возвращаются реальные данные.

Не вызывай "готовое блюдо" по сто раз, если рецепт не менялся. Сделал один раз ToList() — и работай с этим списком.

7. Особо важное для Entity Framework Core (или любого ORM). Тут ошибки самые дорогие, потому что летят в базу данных.

• AsNoTracking() — твой друг для чтения. Говоришь — "не отслеживай изменения этих объектов, мне они только посмотреть". Быстрее будет и памяти меньше жрёт.
• Выбирай только нужные колонки. Зачем тащить из базы все 50 полей огромной сущности, если тебе только Id и Name? Используй Select.
• Фильтруй в БД, а не в памяти. Никогда не делай так: context.Products.ToList().Where(...). Этим ты вытащишь ВСЕ продукты на клиент, а потом отфильтруешь. Делай так: context.Products.Where(...).ToList(). Тогда условие уйдёт в SQL и выполнится на мощном сервере.

И главный совет, на котором мир стоит: Не верь на слово. ВСЕГДА СМОТРИ, КАКОЙ SQL ГЕНЕРИРУЕТ ТВОЙ КОД. Включи логирование в EF Core или используй профайлер для базы. Потому что можно сколько угодно оптимизировать код в памяти, а если там, в запросе, SELECT * и JOIN на десять таблиц без индексов — то всё, пиши пропало, тормоза будут жуткие.