Коллекция вопросов ❓ на собеседовании в C# 🍧

Обзор вопросов по языка програмиированию C# и технологии NET

Project maintained by Dvurechensky-Docs Hosted on GitHub Pages — Theme by mattgraham

🗄️ Как писать эффективные запросы к базе данных из .NET?

✨ Оглавление

✨ Оглавление
- 1️⃣ Почему это важно
- 2️⃣ Основные стратегии для эффективных запросов

⬆ Вернуться к главной

1️⃣ Почему это важно

Неправильная работа с базой данных может привести к:

Медленным запросам и таймаутам.
Перегрузке сервера БД.
Высокому потреблению памяти в приложении.
«N+1» проблемам при ORM.
Некорректной работе кэширования и индексов.

2️⃣ Основные стратегии для эффективных запросов

a) Выбор правильного ORM или уровня доступа

ADO.NET – прямой контроль, самый быстрый вариант, но требует ручного написания SQL и управления параметрами.
Dapper – микрo-ORM, быстрый, легковесный, использует SQL напрямую.
EF Core / NHibernate – удобный, но есть накладные расходы.

Каверзный момент: на собеседовании могут спросить, когда EF Core быстрее ADO.NET и когда наоборот. Ответ: EF Core удобен, но для массовых операций или сложных агрегаций ADO.NET/Dapper будет быстрее.

b) Фильтрация на сервере, а не в памяти

Плохо:

var data = context.Users.ToList().Where(u => u.IsActive);

Хорошо:

var data = context.Users.Where(u => u.IsActive).ToList();

Пояснение: в первом примере ToList() вытягивает все данные, а фильтрация идёт в памяти → нагрузка на память и сеть.

c) Использование проекций

Не вытаскиваем всё: только необходимые поля.

var data = context.Users
                  .Where(u => u.IsActive)
                  .Select(u => new { u.Id, u.Name })
                  .ToList();

Каверзный момент: многие считают, что Select мало влияет. На больших таблицах выгрузка всех колонок — критическая ошибка.

d) Отложенное выполнение (Deferred Execution)

LINQ-запросы в EF Core строят SQL, но не выполняются сразу.

var query = context.Users.Where(u => u.IsActive); // ещё не выполняется
var list = query.ToList(); // здесь SQL выполняется

Каверзный момент: использование foreach вместо ToList() иногда приводит к повторным SQL-запросам (N+1 проблема).

e) Avoid N+1 problem

N+1 проблема: для каждой записи делается дополнительный запрос.

// Плохо
var users = context.Users.ToList();
foreach(var user in users)
    var roles = context.Roles.Where(r => r.UserId == user.Id).ToList();

// Хорошо
var usersWithRoles = context.Users.Include(u => u.Roles).ToList();

Каверзный момент: Include грузит все связанные данные, что может быть тяжело на больших таблицах → иногда лучше использовать отдельные проекции.

f) Пагинация

Никогда не вытаскивать миллионы строк.

var page = context.Users
                  .OrderBy(u => u.Id)
                  .Skip((pageNumber-1) * pageSize)
                  .Take(pageSize)
                  .ToList();

Каверзный момент: без OrderBy SQL Server выдаст непредсказуемый результат при Skip.

g) Использование параметризованных запросов

Для защиты от SQL Injection:

var user = context.Users
                  .FromSqlRaw("SELECT * FROM Users WHERE Name = {0}", userName)
                  .ToList();

Каверзный момент: не использовать string interpolation с пользовательским вводом!

h) Кэширование и отслеживание

AsNoTracking() для чтения данных без отслеживания изменений → меньше памяти и быстрее.

var users = context.Users.AsNoTracking().Where(u => u.IsActive).ToList();

Каверзный момент: если потом пытаешься обновить объекты, нужно помнить, что они «detached».

i) Пакетная вставка/обновление

EF Core по умолчанию делает отдельные INSERT/UPDATE для каждого объекта.
Для больших наборов используем BulkExtensions или Dapper.

context.BulkInsert(users); // через стороннюю библиотеку

Каверзный момент: стандартный EF Core при массовых операциях сильно медленнее ADO.NET.

j) Использование индексов и оптимизация SQL

EF Core сам не создаёт оптимальные индексы.
Важно: анализировать SQL через context.Database.Log или ToQueryString().

var sql = context.Users.Where(u => u.IsActive).ToQueryString();
Console.WriteLine(sql);

Каверзный момент: ORM иногда делает JOIN-ы и подзапросы, которые не нужны — профилируй SQL всегда.

k) Асинхронные запросы

Для Web API и UI потоков лучше использовать async/await.

var users = await context.Users.Where(u => u.IsActive).ToListAsync();

Каверзный момент: асинхронность не ускоряет SQL, но освобождает поток приложения.

l) Минимизировать количество соединений

Использовать using var context = new DbContext(); или DI-синглтон.
Каверзный момент: держать DbContext слишком долго → накопление трекинга объектов, утечки памяти.

⬆ Вернуться к главной

✨Dvurechensky✨