Сейчас из каждого утюга слышу, что работу найти сложно, что на поиск работы надо закладывать 6 месяцев и т.д. и т.п. Ну ОК, подумала я, и вот в октябре начала искать, отрыла резюме на hh.ru для всех желающих, стала повторять теорию, нарешивать задачки и т.д.

Просматриваю вакансии, отбираю в избранное, потом анализирую, что и как там может быть. И наблюдаю за своим резюме. В итоге:
- просмотров резюме - кот наплакал,
- на отклики, релевантные моему опыту - отказы
- предложения только с релокацией в другую страну

Смотрю я статистику своего резюме: последний раз искала работу через HH в 2021 году, просмотров резюме по 10 в день. А сейчас дай бог 3 в неделю.

Резюме у меня одно, я его обновляю и дополняю по мере изменения моего опыта.

Читаю информацию про текущее положение на рынке, везде слышу, что рынок работодателя, что вакансий мало, резюме много. А дальше, очень часто натыкаюсь на то, что все разом говорят - надо делать резюме под конкретную вакансию

Причиной всего этого - автоматизация процессов. Первый скрининг резюме проводит не HR, а AI-агент, настроенный под конкретные триггерные слова.

Раньше мы писали резюме для людей.
Теперь - сначала для алгоритмов

Эпоха универсальных резюме закончилась.
Не потому, что специалисты стали хуже.
А потому что требования стали более структурированными, а инструменты поиска - более автоматизированными.

И теперь у меня вместо одного резюме - 4 резюме, с нотками особенностей под конкретные направления.

Опыт один и тот же.
Но фокус - разный.
И именно фокус видят алгоритмы.

И вот в этой статистике, которую вещает HH.ru - ссылка на презентацию здесь
Говорится о динамики среднего числа вакансий и резюме

Сопоставление вакансий идет к количеству резюме - не к количеству кандидатов.

Если даже возьмем меня, то у меня 4 резюме (планируется еще одно), т.е. количество резюме (в моем случае надо разделить на 4). А если это применить ко всем резюме, то может быть и картина то изменится. И не будем мы использовать слово рынок работодателя - а может быть другой рынок. Например рынок AI-ассистентов

Со стороны соискателей, тоже идет автоматизация. Соискатели в ручную откликаются на 100 вакансий из идеи - а что-то да и сработает. Либо также настраивают автоотклик, автообновление. Все это приводит к тому, что на одну вакансию HR-ы получают 400-3000 откликов, что руками нереально разобрать.

Поэтому компании:
- ставят автоскоринг
- ранжируют по ключевым словам
- убирают резюме, которые хоть чуть-чуть не совпадают
- сортируют по «свежести обновления»

И это не плохо и не хорошо — это новая норма.
Но к ней нужно адаптироваться.

Искать работу в конце 2025 года — это уже не про то, чтобы быть «идеальным кандидатом».
Это про то, чтобы быть заметным в мире, где первые фильтры проходят не люди, а алгоритмы.

Ну а я в своем канале про SQL буду продолжать делиться полезной информацией, интересными задачками и продолжать вдохновлять людей для изучения аналитики.
Если тебе интересно, подписывайся На связи: SQL

Этот канал я веду с нуля.

И так, какие же кейсы есть с применением LIMIT

1. LIMIT + OFFSET

   Многие помнят про LIMIT, но забывают про то, что можно еще применять сдвиг.

   SELECT *
   FROM users
   ORDER BY id
   LIMIT 10 OFFSET 20;

   Этот запрос вернёт 10 строк, начиная с 21-й.

   Такой прием применяется, например, в постраничной выдаче результатов запроса.
   
   Но этот кейс имеет и минусы: OFFSET все равно просматривает первые 20 строк, чтобы добраться до нужных. При больших объемах OFFSET работает медленно.
   

2. LIMIT в UPDATE и DELETE

   Да, да - в этих операторах тоже можно использовать LIMIT, не только в SELECT

   DELETE FROM logs ORDER BY created_at ASC LIMIT 1000;

   Так чистят таблицу порциями, чтобы не завалить базу огромным удалением.
   

3. LIMIT в подзапросах

   Об этом часто помнят, т.к. подзапрос является запросом, а в запросах использование LIMIT - вполне привычное дело.

   
   Найдем самый дорогой заказ:

   SELECT *

   FROM orders

   WHERE id = (SELECT id FROM orders ORDER BY price DESC LIMIT 1);

   Это иногда проще, чем возиться с MAX() и джойнами.
   

4. LIMIT vs FETCH … WITH TIES

   В некоторых СУБД (например, SQL Server, Oracle) есть фича:

   SELECT *

   FROM products

   ORDER BY price DESC

   FETCH FIRST 3 ROWS WITH TIES;

   Такой запрос вернёт не просто 3 строки, а все строки, у которых цена такая же, как у третьей записи.
   (например, если на третьем месте несколько товаров с одинаковой ценой).

   
   LIMIT показывает первые N строк после сортировки
   А вот WITH TIES говорит: «Выдай все строки, которые наравне с последней по значению сортировки».

   
   В других СУБД такой синтаксис можно реализовать через LIMIT + подзапрос с оконной функцией RANK()
   

5. LIMIT 0

   Очень полезный трюк.

   SELECT * FROM users LIMIT 0;

   Вернёт пустую таблицу, но со всеми названиями и типами столбцов.
   Это часто используют для генерации схемы в BI-инструментах или в тестах
   

6. LIMIT в CTE (PostgreSQL)

   Можно ограничивать данные прямо на уровне общего табличного выражения (CTE), чтобы уменьшить нагрузку:

   WITH top_orders AS (

   SELECT * FROM orders ORDER BY price DESC LIMIT 100

   )

   SELECT * FROM top_orders WHERE customer_id = 42;

Так мы сначала берём только 100 дорогих заказов, а потом фильтруем по клиенту.

В итоге LIMIT — это не просто «дай 10 строк», а инструмент для оптимизации, постраничной навигации, аккуратных обновлений и даже для защиты от перегруза.

Подписывайся на мой ТГ канал На связи: SQL, чтобы узнавать/вспоминать еще больше нюансов SQL запросов.

1. Блок с ORDER BY предназначен для сортировки результата выборки.
   По умолчанию сортировка ASC (по возрастанию). Можно явно писать:

ORDER BY age ASC -- от младших к старшим
ORDER BY age DESC -- от старших к младшим

2. Можно сортировать сразу по нескольким столбцам:

ORDER BY country, city

Сначала сортируются страны, внутри них — города.

3. Можно писать не имя, а номер колонки в SELECT:

SELECT name, age
FROM users
ORDER BY 2 DESC; -- сортируем по age

Но это считается «плохим тоном» — лучше явно указывать названия. Хотя мне очень нравится это использовать, особенно, когда в селекте не просто имя столбца, а вычисление.

4. NULL в ORDER BY требует особого внимание.
NULL в разных БД обрабатывается по-разному.

В PostgreSQL:

• ASC → NULL идут в конце

• DESC → NULL идут в начале

можно явно писать:

ORDER BY age ASC NULLS FIRST;
ORDER BY age DESC NULLS LAST;

В MySQL и SQL Server правила отличаются:

• в MySQL NULL всегда считаются «меньше всего» (т.е. идут первыми в ASC).

• в SQL Server можно управлять через ISNULL()/COALESCE().

В MySQL и SQL Server нельзя использовать NULLS FIRST или NULLS LAST при сортировке,

Для SQL Server используем:

ORDER BY ISNULL(age, 9999) ASC;
ORDER BY COALESCE(age, 9999) ASC;

Здесь NULL мы заменяем на большое число (9999), и оно уходит в конец сортировки по возрастанию.
А если хотим NULL в начало — ставим что-то маленькое, например -1.

Для MySQL есть поведение по умолчанию:

• При ASC → NULL идут первые

• При DESC → NULL идут последние

А если нужно наоборот, то делаем хитрость с IS NULL:

ORDER BY age IS NULL, age ASC;

Здесь age IS NULL вернёт 1 для NULL и 0 для обычных значений.
SQL сначала отсортирует по этому условию (0 → 1), а потом уже по age.

5. Можно сортировать не только по полям, но и по функциям.

ORDER BY LENGTH(name) DESC;
ORDER BY purchase_amount * discount;

6. Случайная сортировка - имеет место быть. Но очень "дорога" в использовании на больших объемах.

-- PostgreSQL / SQLite
ORDER BY RANDOM()

-- MySQL
ORDER BY RAND()

Часто случайная сортировка используется при тестировании на небольших объемах.
- хотим показать пользователю случайный товар в магазине
- хотим проверить, как работает приложение, не завися от конкретного порядка записей
- рекомендательные системы: в выдачу добавляем случайный товар, чтобы не зацикливать пользователя только на "популярных" товарах.
- игры или викторины: рандомная выдача вопросов.

7. Есть еще такое понятие как COLLATION (сравнение строк).

ORDER BY учитывает локаль (collation). Поэтому, например, русские буквы могут сортироваться по-разному в разных СУБД:

• А может идти перед а, или наоборот.

• Можно явно указать сортировку:

ORDER BY name COLLATE "C" -- по байтовому значению
ORDER BY name COLLATE "ru_RU" -- по русскому алфавиту

Представь, что у тебя есть список имён:
['Елена', 'елена', 'Жанна', 'Анна']

Когда ты пишешь в SQL:

SELECT * FROM users ORDER BY name;

база должна решить:

• считать ли «Елена» и «елена» одинаковыми?

• что идёт раньше: «Ж» или «А»?

• как сравнивать буквы с диакритикой: «é» vs «e»?

Вот именно на эти вопросы отвечает collation.

То есть COLLATION — это как правило сортировки в библиотеке: от него зависит, где именно окажется твоя книга.

То есть, ORDER BY — это не просто «отсортировать», а ещё и про то:

• куда денутся NULL

• как сортируются строки (с учётом локали)

• можно ли сортировать по выражениям или случайно

В моем ТГ канале На связи: SQL я знакомлю новичков с языком SQL и хочу, чтобы те, кто желает познакомиться с анализом данных с легкостью шли в это направление. Присоединяйся!

Что делают AND и OR

• AND — «и». Все условия должны быть выполнены одновременно.
  Пример: выбрать из холодильника молоко и яйца, чтобы приготовить омлет:

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

(Да, в реальности одной строки с молоком и яйцом не будет, но идея ясна: оба условия должны выполняться вместе.)

OR — «или». Достаточно, чтобы выполнено было хотя бы одно условие.
Пример: выбрать продукты, которые нужно купить или молоко, или яйца:

SELECT *

FROM shopping_list

WHERE product = 'milk' OR product = 'eggs';

Где могут использоваться

Эти операторы обычно используют в блоке WHERE, чтобы фильтровать данные.
Также можно применять их в:

• HAVING — фильтрация агрегатов после GROUP BY

• JOIN ON — комбинирование условий соединения таблиц

Пример с HAVING:

SELECT category, COUNT(*)

FROM fridge

GROUP BY category

HAVING COUNT(*) > 5 AND AVG(expiry_date) < '2025-08-01';

Особенности и нюансы:

• Порядок выполнения важен

  AND имеет более высокий приоритет, чем OR.

  Если смешиваете их, всегда используйте скобки для точного порядка:

  SELECT *

  FROM fridge

  WHERE (product = 'milk' OR product = 'eggs') AND expiry_date < '2025-08-01';

• AND «сжимает» результат, OR «расширяет» результат

  AND оставляет меньше строк, OR — больше

Частые ошибки

• Забыли скобки и получили слишком большой или слишком маленький результат

• Использовали AND там, где нужен OR (или наоборот)

• Смешали NULL значения: NULL AND TRUE и NULL OR TRUE могут вести себя неожиданно

Представим, что мама проверяет холодильник:

• У неё есть список продуктов, которые могут испортиться: молоко, яйца, йогурт

• Она хочет приготовить что-то, если и молоко, и яйца в наличии → AND

• Она хочет перекусить, если есть молоко или йогурт → OR

В SQL это выглядит так:

-- Для приготовления омлета

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

-- Для перекуса

SELECT *

FROM fridge

WHERE product = 'milk' OR product = 'yogurt';

AND и OR — это простые, но мощные инструменты фильтрации. Правильное использование скобок и понимание приоритета операторов помогает избежать ошибок и выбирать точно те данные, которые нужны.

Вот тут и появляется WHERE. Это фильтр, который помогает выбрать именно нужные строки из таблицы — или продукты из холодильника.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Нам нужно выкинуть все продукты, у которых истек срок годности:

SELECT *
FROM fridge
WHERE expiry_date < CURRENT_DATE;

fridge — наша таблица с продуктами
expiry_date < CURRENT_DATE — условие: выбираем просроченные продукты
CURRENT_DATE - текущая дата

Что можно писать в WHERE

• Сравнения: =, >, <, >=, <=

• Логические связки: AND, OR, NOT

• Проверки на вхождение: IN, BETWEEN, LIKE

• Подзапросы: «проверить список покупок перед выбором»

Или, мы хотим приготовить что-то на десерт:

SELECT *
FROM fridge
WHERE category = 'dessert' AND expiry_date > CURRENT_DATE;

Условие AND expiry_date > CURRENT_DATE добавляем на случай, если мы не выкинули всю просрочку до этого.

Подзапросы

В WHERE можно использовать подзапросы. Это когда нам нужна информация из другого источника, чтобы использовать ее в своем запросе. Например, нам надо понять что из рецепта отсутствует у нас в холодильнике.

SELECT *
FROM cooking_recipe
WHERE product NOT IN (SELECT product FROM fridge);

WHERE проверяет какие продукты отсутствуют в холодильнике.

Аналогично можно использовать EXISTS или NOT EXISTS
SELECT *
FROM fridge f
WHERE EXISTS (SELECT 1 FROM cooking_recipe s WHERE s.product = f.product);

EXISTS = есть продукт в списке
NOT EXISTS = нет продукта в списке

ANY \ ALL

Эти конструкции позволяют сравнивать с набором значений.

SELECT *
FROM fridge
WHERE expiry_date <= ALL (SELECT expiry_date FROM fridge WHERE category = 'milk');

Все хорошие домохозяйки используют принцип ротации. Выбирают продукты, срок годности которых меньше всех в категории “молоко”.

• Подзапрос (SELECT expiry_date FROM fridge WHERE category = 'milk') возвращает даты всех банок молока.

• Условие expiry_date <= ALL (...) означает: выбрать только те банки, у которых дата годности меньше или равна каждой другой банке молока.

• Практически это банка (или несколько, если даты совпадают), которая старше всех остальных.

То есть, результат будет одна или несколько банок с самой ранней датой годности.

SELECT *
FROM fridge
WHERE expiry_date <= ANY (SELECT expiry_date FROM fridge WHERE category = 'milk');

• Условие expiry_date <= ANY (...) означает: выбрать все банки молока, у которых дата годности меньше или равна хотя бы одной другой банке молока.

• Тут почти все банки проходят условие, кроме самой свежей (если она самая большая по сроку).

• Результат может быть несколько банок, не обязательно только одна. Все, кто «моложе или равны хотя бы одной другой», будут выбраны.

CASE в WHERE

Можно использовать CASE для сложной логики

SELECT *
FROM fridge
WHERE
CASE
WHEN product = 'milk' THEN shelf = 'top'
ELSE shelf = 'middle'
END;

Если я ищу молочные продукты в холодильнике, то должна их искать на самой верхней полке, иначе - на средней.

Ну а если тебе нужны слова поддержки и мотивации, то заглядывай в канал Сила слов. Там каждое утро приходит мотивационное сообщение для тебя, чтобы ты верил себе и в себя, продолжал или только начинал действовать.