SQL

БЛОК 2. Чтение данных — 6. SELECT + WHERE

📚 22 вопросовПройти тест →
Лекция

БЛОК 2. Чтение данных — 6. SELECT + WHERE

SQL

6. SELECT + WHERE

🧭 Введение: почему чтение данных начинается с SELECT + WHERE

Когда в проекте появляется таблица, следующий вопрос всегда один: как быстро и точно достать нужные записи.
Именно здесь начинается базовая аналитика, отчётность, админка и большая часть API-методов чтения.
SELECT отвечает на вопрос «какие поля показать», а WHERE — «какие строки вообще подходят».
Если неправильно задать фильтр, можно вернуть лишние данные, сломать отчёт или не найти нужную запись.
💡 Совет: Сначала формулируйте запрос человеческой фразой («покажи активные заказы за сегодня»), а потом переводите её в SQL.
✅ Вывод: SELECT + WHERE — это базовый навык чтения данных, от которого зависит корректность почти всех экранов и отчётов.

⚠️ Проблема -> решение

Без структуры запросов команды часто пишут «рабочий, но случайный» SQL: выбирают *, забывают условия, смешивают AND/OR без скобок.
В результате API отдаёт не те данные, а поиск в интерфейсе ведёт себя непредсказуемо.
Решение — строить запрос по чёткому алгоритму:
  1. определить таблицу и поля (SELECT ... FROM ...),
  2. явно зафиксировать условия (WHERE ...),
  3. проверить логику комбинаций условий,
  4. сделать запрос читаемым через алиасы.
🟢 Если совсем просто: Сначала решаем «что показать», потом — «что отфильтровать», и только затем шлифуем читаемость.
🎯 Как понять, что этап прошёл успешно: Запрос возвращает ровно те строки, которые ожидались в бизнес-сценарии, без «лишнего шума».

🛠️ Чем помогает и как работает

Грамотный SELECT + WHERE уменьшает число ошибок в чтении данных и ускоряет отладку.
Это база для сложных тем: сортировки, агрегации, JOIN, подзапросов.
🟢 Если совсем просто: Это язык, на котором вы задаёте БД вопрос и получаете точный ответ.
🎯 Как понять, что этап прошёл успешно: Любой фильтр в интерфейсе можно прозрачно объяснить соответствующим условием в SQL.
Чем помогает:
  • убирает неоднозначность в запросах;
  • снижает риск логических ошибок в фильтрации;
  • делает SQL читаемым для команды;
  • готовит основу для производительной аналитики.
Как это работает:
  • Шаг 1: выбираем источник данных (FROM).
  • Шаг 2: перечисляем нужные колонки в SELECT вместо безусловного *.
  • Шаг 3: задаём фильтр через WHERE и операторы сравнения.
  • Шаг 4: при нескольких условиях фиксируем приоритет скобками.
  • Шаг 5: добавляем алиасы, чтобы запрос читался как документ.
  • Шаг 6: проверяем результат на мини-наборе тестовых кейсов.
✅ Вывод: SELECT + WHERE — это не «синтаксис ради синтаксиса», а управляемая логика отбора данных.

📚 Ключевые термины (простыми словами)

Перед практикой полезно синхронизировать словарь, чтобы одинаково читать и ревьюить запросы.
🟢 Если совсем просто: Это минимальный набор слов, без которого сложно обсуждать SQL в команде.
🎯 Как понять, что этап прошёл успешно: Вы можете объяснить каждый термин на примере своего запроса.
  • SELECT (выборка) — какие колонки вернуть в результате.
  • FROM (источник) — из какой таблицы читать данные.
  • WHERE (фильтр) — какие строки оставить.
  • Comparison operators (операторы сравнения) — =, <>, >, >=, <, <=.
  • Logical operators (логические операторы) — AND, OR, NOT для комбинации условий.
  • Alias (алиас/псевдоним) — короткое имя колонки или таблицы в рамках запроса.
  • Predicate (предикат) — условие, которое возвращает true/false для каждой строки.
  • NULL (отсутствующее/неизвестное значение) — специальное состояние, которое нельзя сравнивать обычным = или <>.
✅ Вывод: Общий словарь снижает число ошибок «из-за разного понимания одного и того же запроса».

🔎 1. Базовый SELECT: что выбрать и откуда

Самая частая ошибка новичка — начинать с SELECT * и только потом пытаться понять, какие поля реально нужны.
Это усложняет чтение результата и увеличивает объём лишних данных.
🟢 Если совсем просто: Чем точнее список колонок, тем понятнее и аккуратнее запрос.
🎯 Как понять, что этап прошёл успешно: В выдаче нет случайных колонок, и каждое поле в результате можно обосновать бизнес-задачей.
Назначение: Получать только те поля, которые действительно нужны для экрана, отчёта или API.
Простыми словами: SELECT — это список того, что вы просите показать.
Для новичка: Если вам нужны имя, email и статус, не просите всю строку целиком.
Чем меньше лишнего, тем проще проверять результат.
Аналогия: Это как заказывать в магазине только нужные товары, а не «весь склад сразу».
Пример:
SELECT  id,  full_name,  email,  is_activeFROM users;
🔎 Как это происходит на практике:
  • Контекст: backend делает endpoint списка пользователей для админки.
  • Действия: команда выбирает только нужные поля для таблицы в UI.
  • Результат: ответ API компактный, понятный и без «мусорных» данных.
Характеристики:
  • явный список колонок повышает читаемость;
  • легче отлавливать ошибки в контракте API;
  • проще контролировать чувствительные поля (например, не выдать лишнее).
Когда использовать: Всегда, когда есть конкретная цель выборки; SELECT * допустим только для быстрой локальной диагностики.
✅ Вывод: Точный SELECT — это базовая дисциплина качества данных в ответе.

🎯 2. WHERE и операторы сравнения: точный фильтр

WHERE — ядро фильтрации.
Именно здесь определяется, какие строки останутся в результате, а какие будут отброшены.
🟢 Если совсем просто: WHERE — это правило отбора строк «покажи только те, где условие истинно».
🎯 Как понять, что этап прошёл успешно: Вы можете руками проверить 3-5 строк и точно предсказать, попадут они в результат или нет.
Назначение: Ограничить выборку только релевантными строками.
Простыми словами: Операторы сравнения позволяют задать математические и логические границы для поля.
Для новичка: Начните с простого условия (status = 'active'), выполните запрос, затем добавляйте сложность по одному правилу.
Аналогия: Это как фильтр в маркетплейсе: цена до 5000, рейтинг выше 4, доставка сегодня.
Пример:
SELECT  id,  user_id,  status,  total_amountFROM ordersWHERE status = 'paid'  AND total_amount >= 1000  AND total_amount < 10000;
🔎 Как это происходит на практике:
  • Контекст: финансовый отдел запрашивает оплаченные заказы в целевом диапазоне сумм.
  • Действия: разработчик собирает фильтр через =, >=, <.
  • Результат: отчёт строится по нужному сегменту без ручной чистки.
Характеристики:
  • = и <> работают как «равно / не равно»;
  • >, >=, <, <= задают границы диапазонов;
  • условия в WHERE применяются к каждой строке отдельно.
Мини-пример для NULL:
SELECT  id,  phoneFROM customersWHERE phone IS NULL;
= NULL и <> NULL не дают ожидаемого результата, потому что NULL — это «неизвестно», а не обычное значение.
Для таких проверок используйте только IS NULL / IS NOT NULL.
Когда использовать: При любом чтении, где нужны не все строки таблицы, а конкретный бизнес-срез.
✅ Вывод: WHERE превращает «выгрузку всего» в точный инструмент отбора.

🧠 3. Множественные условия: AND, OR, NOT и скобки

Когда бизнес-правило становится сложнее одного фильтра, подключаются логические операторы.
Главная боль здесь — неверный приоритет операций, особенно при смешивании AND и OR.
🟢 Если совсем просто: AND — нужно выполнить всё, OR — достаточно одного, NOT — исключаем условие.
🎯 Как понять, что этап прошёл успешно: Вы явно используете скобки в спорных местах и получаете ожидаемое количество строк.
Назначение: Комбинировать фильтры так, чтобы SQL отражал реальное бизнес-правило.
Простыми словами: Логические операторы связывают несколько проверок в одно итоговое решение.
Для новичка: Если в условии есть и AND, и OR, ставьте скобки сразу.
Это защищает от «тихих» ошибок, когда запрос синтаксически верный, но логически неправильный.
Аналогия: «Пустить на мероприятие тех, кто в списке гостей и старше 18, или сотрудников по пропуску».
Пример:
SELECT  id,  status,  total_amount,  cityFROM ordersWHERE (status = 'paid' OR status = 'shipped')  AND total_amount >= 3000  AND city <> 'test-city';
🔎 Как это происходит на практике:
  • Контекст: маркетинг строит выборку для кампании по активным заказам.
  • Действия: команда объединяет статусы через OR, а обязательные критерии — через AND.
  • Результат: сегмент без шумовых и тестовых записей.
Характеристики:
  • AND сужает выборку;
  • OR расширяет выборку;
  • NOT инвертирует условие;
  • скобки управляют приоритетом и снимают неоднозначность.
Когда использовать: Когда бизнес-условие состоит из нескольких критериев, которые нельзя выразить одним сравнением.
✅ Вывод: Множественные условия безопасны только тогда, когда приоритет явно задан скобками.

🧩 4. Операторы для практичной фильтрации: IN, BETWEEN, LIKE, ILIKE

В реальных запросах часто нужен не один точный матч, а список вариантов, диапазон или поиск по шаблону.
Для этого удобны IN, BETWEEN, LIKE и ILIKE (в PostgreSQL).
🟢 Если совсем просто: IN — список значений, BETWEEN — диапазон, LIKE/ILIKE — шаблон строки.
🎯 Как понять, что этап прошёл успешно: Запрос проще читать, чем длинная цепочка однотипных OR.
Назначение: Сделать фильтры компактными и читаемыми для типовых сценариев отбора.
Простыми словами: Эти операторы сокращают «многословные» условия в понятные конструкции.
Для новичка: Если у вас три и более одинаковых проверки по одному полю, почти всегда стоит проверить, можно ли заменить их на IN.
Аналогия: Это как фильтры в приложении: «статусы из списка», «цена от и до», «имя начинается с A».
Пример:
SELECT  id,  status,  total_amount,  created_atFROM ordersWHERE status IN ('new', 'paid', 'shipped')  AND total_amount BETWEEN 1000 AND 5000  AND customer_email ILIKE '%@company.com';
🔎 Как это происходит на практике:
  • Контекст: support ищет корпоративные заказы со статусами в заданном пуле.
  • Действия: вместо длинных OR команда использует IN, а диапазон оформляет через BETWEEN.
  • Результат: запрос короче, легче читать и проще поддерживать.
Характеристики:
  • IN (...) удобен для конечного списка значений;
  • BETWEEN a AND b включает обе границы;
  • LIKE применяется для шаблонного поиска в строках;
  • в PostgreSQL ILIKE даёт case-insensitive поиск по шаблону;
  • LIKE 'abc%' часто лучше дружит с индексами, чем LIKE '%abc%' (зависит от СУБД и коллации);
  • LIKE '%abc%' часто требует полный проход или специальный индекс (например, триграммы в PostgreSQL).
Важная оговорка для дат и времени: BETWEEN включает обе границы, и для TIMESTAMP это часто ловушка.
-- Плохо для "за 2026-03-05": почти ничего не вернёт, кроме полуночиWHERE created_at BETWEEN TIMESTAMP '2026-03-05 00:00:00'                    AND TIMESTAMP '2026-03-05 00:00:00' -- Лучше: полуинтервалWHERE created_at >= TIMESTAMP '2026-03-05 00:00:00'  AND created_at <  TIMESTAMP '2026-03-06 00:00:00'
Когда использовать: Когда фильтр естественно описывается списком, диапазоном или строковым шаблоном.
✅ Вывод: IN/BETWEEN/LIKE/ILIKE делают SQL ближе к реальному языку бизнес-условий.

🏷️ 5. Алиасы в запросах: AS для колонок и таблиц

Когда запрос растёт, без алиасов он становится «шумным»: длинные имена колонок, повтор таблиц, неочевидные заголовки результата.
Алиасы решают это без изменения самих данных.
🟢 Если совсем просто: Алиас — это удобное временное имя в пределах одного запроса.
🎯 Как понять, что этап прошёл успешно: Запрос читается слева направо без «расшифровки», а названия столбцов в результате понятны бизнесу.
Назначение: Сделать запрос и его результат более читаемыми и удобными для использования.
Простыми словами: AS позволяет переименовать колонку или таблицу только на время выполнения запроса.
Для новичка: Используйте алиасы, если без них запрос тяжело читать глазами.
Хорошее имя алиаса должно объяснять смысл поля, а не быть случайной аббревиатурой.
Аналогия: Это как подписать коробки на складе короткими понятными ярлыками.
Пример:
SELECT  o.id AS order_id,  o.created_at AS order_created_at,  o.total_amount AS amount,  o.status AS order_statusFROM orders AS oWHERE o.status = 'paid'  AND o.total_amount >= 2000;
🔎 Как это происходит на практике:
  • Контекст: frontend ждёт поля с предсказуемыми именами.
  • Действия: backend задаёт алиасы колонок под контракт API.
  • Результат: уменьшается число преобразований и путаницы на стороне клиента.
Характеристики:
  • алиасы колонок улучшают читабельность результата;
  • алиасы таблиц сокращают запись и упрощают фильтры;
  • AS повышает поддержку сложных запросов и ревью кода.
Когда использовать: Когда нужно улучшить читаемость запроса, унифицировать названия для API или убрать неоднозначность.
✅ Вывод: Алиасы — простой способ сделать SQL понятным для разработчиков и бизнеса.

⚖️ Сравнение операторов фильтрации

ОператорДля чего использоватьЧастая ошибка
=точное совпадениесравнивать с неправильным типом значения
<>исключить конкретное значениезабывать, что это только одно значение
> / <строгие границыперепутать направление сравнения
>= / <=границы с включениеможидать исключение границы
IN (...)список допустимых значенийписать длинную цепочку OR вместо IN
BETWEEN ... AND ...диапазон с обеими границамидумать, что верхняя граница исключена
LIKE / ILIKEстроковый шаблон (с/без учёта регистра)ставить %...% без понимания влияния на индексы
✅ Вывод: Оператор выбирают по смыслу фильтра, а не «по привычке из прошлого запроса».

📌 Must-know факты

  • SELECT без WHERE вернёт все строки таблицы.
  • SELECT * удобен для черновой проверки, но плох как стандарт в production-коде.
  • В смешанных условиях AND/OR безопаснее всегда использовать скобки.
  • Для отсутствующих значений используйте IS NULL / IS NOT NULL, а не = NULL.
  • Для диапазонов по TIMESTAMP чаще безопаснее полуинтервал >= start AND < next_day.
  • Алиасы не меняют данные в таблице, они работают только в текущем запросе.
  • Читаемость запроса напрямую влияет на скорость ревью и поддержку.
  • Сначала корректность логики, затем оптимизация.

🧨 Частые мифы

❌ Миф:
SELECT * — нормальный стандарт для любого запроса.
✅ Как правильно:
Выбирайте только нужные поля, особенно в API и отчётах.
📎 Почему это важно:
Меньше лишних данных, меньше риска утечки и проще сопровождение.
❌ Миф:
Если запрос выполнился без ошибки, фильтр точно корректный.
✅ Как правильно:
Проверяйте бизнес-логику на тестовых кейсах и количество возвращённых строк.
📎 Почему это важно:
Логическая ошибка в WHERE часто не даёт SQL-ошибку, но ломает результат.
❌ Миф:
AND и OR можно писать подряд без скобок, БД «и так поймёт».
✅ Как правильно:
Явно задавайте приоритет через скобки.
📎 Почему это важно:
Иначе легко получить неожиданную выборку и скрытый баг в отчётах.
❌ Миф:
Алиасы нужны только для очень сложных запросов.
✅ Как правильно:
Используйте алиасы в любых запросах, где они повышают читаемость.
📎 Почему это важно:
Понятный SQL быстрее ревьюится и легче передаётся между разработчиками.

❓ Часто спрашивают на собеседованиях

❓ Вопрос: Чем SELECT * хуже явного списка колонок? ✅ Ответ: Явный список даёт контроль над контрактом, снижает шум и уменьшает риск вернуть лишние данные.
❓ Вопрос: Какой приоритет у AND и OR в WHERE? ✅ Ответ: Без скобок приоритет выше у AND, поэтому смешанные условия лучше всегда группировать скобками.
❓ Вопрос: Когда использовать IN, а не много OR? ✅ Ответ: Когда сравниваете одно поле с конечным списком значений; IN делает запрос короче и понятнее.
❓ Вопрос: Что даёт алиас колонки через AS? ✅ Ответ: Понятное имя поля в результате запроса, удобное для API, отчётов и дальнейшей обработки.
❓ Вопрос: Можно ли считать WHERE только «фильтром для UI»? ✅ Ответ: Нет, WHERE — часть бизнес-логики данных и ключевой элемент корректности выборки.
❓ Вопрос: Почему полезно сначала писать простой фильтр, а потом усложнять? ✅ Ответ: Пошаговая сборка облегчает проверку логики и быстрее выявляет ошибочный кусок условия.

🚫 Типичные ошибки

Ошибка 1: всегда писать SELECT *

❌ Неправильно:
Брать все колонки даже для короткого списка в интерфейсе.
✅ Правильно:
Явно перечислять поля под конкретную задачу.
Почему:
Так запрос легче поддерживать и безопаснее использовать в API.

Ошибка 2: забывать WHERE в «боевом» запросе

❌ Неправильно:
Запрос для отчёта без фильтра по периоду/статусу.
✅ Правильно:
Явно задавать обязательные фильтры.
Почему:
Иначе легко получить огромную и неверную выборку.

Ошибка 3: смешивать AND и OR без скобок

❌ Неправильно:
Надеяться на «интуитивный» приоритет.
✅ Правильно:
Ставить скобки в каждом неоднозначном выражении.
Почему:
Синтаксис может быть корректным, а бизнес-логика — нет.

Ошибка 4: использовать неинформативные алиасы

❌ Неправильно:
Писать a, b, c, если запрос читает вся команда.
✅ Правильно:
Давать алиасы, отражающие смысл (order_total, customer_email).
Почему:
Понятные имена снижают когнитивную нагрузку при ревью.

Ошибка 5: пытаться решить все условия в одном длинном выражении сразу

❌ Неправильно:
Писать сложный WHERE «в один заход» без промежуточной проверки.
✅ Правильно:
Собирать фильтр по частям и проверять результат после каждого шага.
Почему:
Так быстрее найти ошибку и доказать корректность логики.

✅ Best Practices

  • Формулируйте условие в человеческом виде до написания SQL.
  • Используйте явный список колонок вместо SELECT * в рабочем коде.
  • При смешивании AND/OR всегда расставляйте скобки.
  • Для списков значений используйте IN, для диапазонов — BETWEEN.
  • Для NULL-проверок используйте только IS NULL / IS NOT NULL.
  • Для поиска без учёта регистра в PostgreSQL используйте ILIKE осознанно и учитывайте индексацию.
  • Давайте осмысленные алиасы колонкам, которые уходят в API/отчёты.
  • Проверяйте запрос на маленьком тестовом наборе, прежде чем запускать на полном объёме.

🧾 Заключение

SELECT + WHERE — фундамент чтения данных в SQL.
Через эти конструкции строятся почти все пользовательские списки, фильтры и отчёты.

Ключевые мысли

  • SELECT определяет структуру ответа, WHERE — его точность.
  • Операторы сравнения и логические связки нужно выбирать по бизнес-смыслу.
  • Скобки и алиасы делают запрос безопасным и читаемым.
  • Сильная база в SELECT + WHERE упрощает изучение следующих тем SQL.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 2. Чтение данных — 6. SELECT + WHERE»

Пройти тест →