Декартово произведение в SQL.
4 запроса, которые могут стоить дорого.

Сегодня разберём одну опасную вещей в SQL — декартово произведение.

У нас есть таблицы:

- products — 77 строк
- order_details — 2155 строк

Теперь немного математики.

Если мы случайно получим декартово произведение, результат будет:
77 × 2155 = 165 935 строк (Сто шестьдесят пять тысяч девятьсот тридцать пять строк).

Из двух вполне обычных таблиц.
Так как же получается декартово произведение в SQL запросах ?
-----------------------------------------------
Вариант №1 — очевидный

SELECT *
FROM products
CROSS JOIN order_details;

Это честное декартово произведение.

CROSS JOIN = «каждую строку первой таблицы соединить с каждой строкой второй».

Здесь всё прозрачно.
Если вы так написали — вы сделали это осознанно.

-----------------------------------------------
Вариант №2 — старый синтаксис

SELECT *
FROM products, order_details;

Это то же самое.

Если нет условия в WHERE, это снова 77 × 2155.

Многие забывают, что запятая в FROM — это тоже JOIN.

А теперь начинается интересное.

-----------------------------------------------
Вариант №3 — ошибка невнимательности

SELECT *
FROM products p, order_details od
WHERE p.product_id = p.product_id;

На первый взгляд — условие есть.
Но если внимательно посмотреть: p.product_id = p.product_id

Мы сравниваем столбец сам с собой. Это всегда TRUE.

Условие никак не связывает таблицы.
А значит — снова декартово произведение.
И вот это уже опасно.
Потому что визуально кажется, что JOIN есть.

-----------------------------------------------
Вариант №4 — более современный, но та же проблема

SELECT *
FROM products p
JOIN order_details od ON p.product_id = p.product_id;

Та же логика.
Условие соединения не использует вторую таблицу.
Это всё равно что написать: ON TRUE

И снова: 77 × 2155 = 165 935 строк.

-----------------------------------------------
Почему это действительно опасно

1️⃣ Взрыв строк

165 тысяч строк вместо ожидаемых 2155.
А если таблицы больше?
10 000 × 1 000 000 = 10 миллиардов строк.

2️⃣ Ложная аналитика

Если вы потом делаете:

SUM(price)
COUNT(*)
AVG(...)

Все значения будут очень сильно раздуты.

3️⃣ Нагрузка на сервер

База честно начинает соединять всё со всем.

- растёт время выполнения
- растёт нагрузка
- появляется seq scan + nested loop

И дальше уже вопрос к нам, а не к PostgreSQL.

Почему SQL и работа с данными в 2026 году — это уже необходимость, а не “плюс к резюме”

Мир окончательно стал цифровым.
Решения принимаются на основе данных.
Продукты строятся на данных.
ИИ обучается на данных.

И вот здесь важный момент.

Данные сами по себе обладают ценностью.
Но гораздо большую ценность имеет умение с ними работать.

📊 Факт №1. SQL — один из самых востребованных навыков

По данным hh.ru (публикация Myseldon), знание SQL упоминается примерно в 12% IT-вакансий.
Для сравнения: Linux — около 9%, Python — около 8%.

Это говорит о простом:

SQL нужен не только аналитикам.
Он нужен разработчикам, администраторам, инженерам данных.

Это инфраструктурный навык.

📈 Факт №2. Спрос на специалистов по базам данных растёт

По публикациям отраслевых изданий (например, CNews), за последние годы заметно вырос спрос на специалистов по PostgreSQL и работе с базами данных.

Компании масштабируют системы, переходят на современные СУБД, строят аналитические платформы.

А значит — нужны люди, которые понимают:

- реляционную модель
- архитектуру хранения данных
- производительность запросов
- корректность соединений

🤖 Факт №3. ИИ усиливает значение работы с данными

Да, генеративный ИИ умеет писать SQL.

Но он не отвечает за:

- корректность бизнес-логики
- качество исходных данных
- понимание, почему JOIN дал 165 935 строк вместо 2155
- контроль дублирования
- корректные границы дат
- и многое другое

ИИ ускоряет работу.
Но ответственность остаётся у человека.

💰 Факт №4. Навык напрямую влияет на доход

По данным публикаций на основе рынка вакансий, специалисты, уверенно владеющие SQL и работающие с данными, могут рассчитывать на хорошие и конкурентные зарплатные предложения (в зависимости от уровня и региона).

Важно понимать: платят не за “знание SELECT”.
Платят за умение превращать данные в решения.

🧠 Что происходит в 2026

Компании уже не экспериментируют с данными — они на них опираются.

А это значит:

- ошибки стоят дорого
- неверные агрегаты и JOIN могут влиять на стратегию
- аналитика становится частью управления

И в этой реальности SQL — это не инструмент “для айтишников”.
Это язык общения с бизнес-логикой.

💎 Вывод

В 2026 году SQL — это цифровая грамотность.

Можно пользоваться AI.
Можно пользоваться BI-инструментами.
Можно пользоваться готовыми платформами.

Но если нет понимания структуры данных и логики запросов — будет потолок.

Технологии меняются.
Данные — остаются.
А специалисты, которые умеют с ними работать, всегда будут востребованы.

Учитесь, учитесь и учитесь и будет вам счастье!

Жиза: как ты объясняешь маме, чем занимаешься на работе

— Мам, я работаю с базами данных.
— А, ну как Люда из бухгалтерии, в Excel таблички вбиваешь?
— Ну… типа того, только большие.
— А-а-а, понятно. А когда женишься?

Самое смешное, что когда пытаешься объяснить нормально, становится только хуже:

— Я пишу запросы на SQL, чтобы доставать информацию из таблиц.
— А зачем её доставать, она что, упала?
— …

Бабушка (с подозрением):
— А это вообще безопасно? Эти ваши базы данных… вдруг утечка? Вон по телевизору говорят, что данные воруют.
— Бабуль, я просто смотрю, кто сколько товаров купил.
— Ох, смотри, внучок, осторожнее. А то напишут на тебя чего.

(Бабушка, меня больше беспокоит, что я могу случайно DROP TABLE написать.)

Папа (смотрит новости про нейросети):
— Сын, а вы там уже пользуетесь этим… как его… ИИ?
— Пользуемся, пап. Помогает.
— И что, теперь сам за вас запросы пишет?
— Ну, если правильно попросить — может и написать.
— Так, может, тогда ты его попроси, а сам на рыбалку?
— Пап, а если он на рыбалку захочет?
— …Ладно, работайте как знаете.

(Пап, спасибо, что беспокоишься о моём досуге.)

Коллега спросил: можно ли сделать JOIN двух таблиц, если у них нет ключей соединения?

Многие сразу отвечают: нет.
Но правильный ответ — да, можно.

JOIN — это просто способ соединить строки двух таблиц по какому-то условию. Это условие совсем не обязано быть первичным и внешним ключом. Главное — чтобы было логическое правило, по которому строки можно сопоставить.

Например, задача из аналитики.

Есть таблица clients:

- client_id
- name
- city

И таблица managers:

- manager_id
- name
- city

Нужно найти клиентов и менеджеров, которые живут в одном городе.

SELECT c.name AS client,
       m.name AS manager,
       c.city
FROM clients c
JOIN managers m ON c.city = m.city;

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

Важно помнить один момент:
если в городе 5 клиентов и 3 менеджера, результат будет 15 строк. SQL соединит каждого клиента с каждым менеджером. Поэтому при JOIN без ключей строки часто «умножаются».

Другой пример.

Есть таблица clients с датой выдачи карты и таблица orders с покупками. Нужно найти клиентов, которые совершали покупки в день получения карты.

SELECT c.client_id,
       o.order_id,
       o.order_date
FROM clients c
JOIN orders o
ON c.client_id = o.client_id AND o.order_date = c.card_issue_date;

Вывод простой:
JOIN — это не про ключи. JOIN — это про условие, которое логически связывает данные (хотя конечно JOIN по ключам будет наиболее эффективен).

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

Почему в PostgreSQL таблицы толстеют, даже если вы ничего не добавляете?

Представьте: вы делаете ремонт. Купили новый диван, старый решили выбросить. Но вместо того, чтобы вынести его на помойку, вы просто пододвигаете его к стенке и ставите новый рядом.

Комната та же. Места не прибавилось, места стало наоборот меньше. Дивана теперь два, только вот один из них вам уже не нужен и использовать вы его не будете.

Примерно так работает PostgreSQL, когда вы обновляете или удаляете данные.

Смотрите сами.

Допустим, есть пустая таблица: users

Вставляем туда одну строку:

INSERT INTO users VALUES (1, 'Иван', 'ivan@mail.ru');

В таблице одна строка. Всё хорошо.

Теперь Иван решил сменить почту. Выполняем UPDATE:

UPDATE users
SET email = 'ivan@yandex.ru'
WHERE id = 1;

С точки зрения человека — мы просто исправили поле.
С точки зрения PostgreSQL — мы создали новую версию строки, а старую пометили как «мёртвую». В PostgreSQL нет ластика, которым можно просто стереть часть строки и записать туда новую информацию. Это работает иначе.

Физически в таблице теперь лежат две строки. Одна живая, одна мёртвая. Живая строка с новой информацией про Ивана, а мертвая со старой.

То же самое с DELETE:

DELETE FROM users WHERE id = 1;

С точки зрения PostgreSQL — строка не исчезает. Она просто получает отметку «не в строю». Лежит там же, занимает место, но в выборку при написании SELECT не попадает.

Эти «мёртвые» строки и есть тот самый мусор.

Со временем, если таблица живёт активной жизнью — обновляется, удаляется, снова обновляется — мёртвых строк может становится все больше и больше.

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

К счастью для уборки в PostgreSQL есть свой «дворник» — процесс VACUUM. Он ходит по таблицам, находит мёртвые строки и вычищает их. Свободное место становится доступным для новых строк.

Но если мусора слишком много, а дворник не успевает — таблица продолжает пухнуть.

К чему это я?

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

Что делать, если кажется, что SQL — это не твоё

Знакомое чувство: сидишь над задачей, смотришь на запрос…
и в голове пустота.

Читаешь условие уже третий раз.
Пробуешь написать SELECT — не получается.
Потом вроде начинает получатся, но приходит он — JOIN и все опять посыпалось. А дальше еще подзапросы выглядывают из за угла...

И в какой-то момент появляется мысль:
«Наверное, это просто не моё».

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

Я тогда открыл задачу, посмотрел на OVER (PARTITION BY ...)
и честно подумал:
«Ну всё… дальше базового SQL я не пройду».

Потому что обычные запросы вроде стали понятны:
SELECT, JOIN, GROUP BY.

А тут внезапно новые сложности:

ROW_NUMBER() OVER (PARTITION BY ...)

И кажется, что ты читаешь какой-то другой язык.

Я несколько раз пытался решить задачу.
Не получилось.

Потом закрыл ноутбук и подумал:
«Ладно. Вернусь завтра».

На следующий день снова открыл пример, разобрал его по частям:

- что делает PARTITION BY
- чем это отличается от GROUP BY
- зачем нужен ORDER BY внутри окна

И постепенно картинка начала складываться.

Не сразу. Не за один вечер.

Но в какой-то момент ты вдруг ловишь себя на мысли:
«А ведь это на самом деле работает логично».

И вот что важно понять.

Когда вы учите SQL, вы не соревнуетесь с теми,
кто пишет запрос за 10 секунд.

Вы соревнуетесь только с собой вчерашним.
Но сегодня мы должны становиться лучше, чем вчера.

Сегодня вы не понимаете JOIN.
Завтра начинаете понимать.
Через месяц спокойно используете оконные функции.

Это нормальный процесс.

Поэтому если иногда кажется, что SQL — это «не твоё»,
просто помни одну вещь:

Почти каждый, кто сейчас пишет сложные запросы, когда-то сидел над простым SELECT и тоже ничего не понимал.

Так что спокойно.

Ошибаться можно. Не понимать — можно.

Главное — не бросать.

Как я объяснял начальнику, почему нельзя просто взять и "починить базу"

Ситуация: утро понедельника, я только налил кофе, как влетает шеф:

— Слушай, тут проблема. Сайт тормозит. Клиенты жалуются. Сделай что-нибудь.

Я (спокойно): — Хорошо, сейчас посмотрю логи, проверю нагрузку, maybe индексы нужно подкрутить или запросы оптимизировать.

Шеф (нетерпеливо): — Слушай, не надо этих сложностей. Ты ж программист. Просто зайди в базу и почини.

Я: — ??

Шеф: — Ну там, кнопку нажми какую-нибудь. "Починить базу". Должна же быть такая кнопка?

Я пытаюсь объяснить, что база данных — это не холодильник, где есть волшебная кнопка "разморозка". Что нужно смотреть планы запросов, искать узкие места, maybe добавлять индексы, чистить мёртвые строки, проверять блокировки...

Шеф смотрит на меня как на инопланетянина:

— Слушай, ты меня грузишь. Вот у меня в машине — заглохла, открыл капот, постучал молотком, и поехала. А у тебя не так?

Я: — Ну, если я постучу молотком по серверу, он точно не поедет. Скорее, упадёт окончательно.

Шеф вздыхает: — Ладно, делай по-своему. Только быстро. И без этих ваших умных слов.

Я иду искать проблему. Нахожу: один кривой запрос от новой фичи делал полное сканирование огромной таблицы. Добавил индекс — всё полетело.

Прихожу к шефу: — Готово. Я там индекс навесил, теперь летает.

Шеф (с подозрением): — Индекс? Это типа оглавление в книжке?

Я: — Ну... да, типа того.

Шеф (довольно): — Вот видишь, а говорил сложно. Просто оглавление добавил. Я ж говорил — ничего сложного.

Я промолчал. Пусть думает, что я просто "кнопку нажал".

Оконные функции ранжирования в PostgreSQL

Когда нужно отсортировать строки и присвоить им место в рейтинге, в PostgreSQL используют оконные функции ранжирования.

Они работают через конструкцию OVER(), которая определяет окно строк, внутри которого происходит вычисление.

Чаще всего используется такой шаблон:

`FUNCTION() OVER (PARTITION BY ... ORDER BY ...)`

PARTITION BY — делит данные на группы
ORDER BY — задаёт порядок внутри группы

Теперь разберём основные функции ранжирования.

---------------------------------------------------------------------------------------------

ROW_NUMBER()

Присваивает уникальный номер каждой строке.

Даже если значения одинаковые — номера всё равно будут разными.

Пример:

`ROW_NUMBER() OVER (ORDER BY salary DESC)`

Где используется:

— нумерация строк
— выбор top N записей
— удаление дубликатов

Главная особенность:
никакие значения не считаются равными — у каждой строки свой номер.

---------------------------------------------------------------------------------------------

RANK()

Функция ранжирования с учётом одинаковых значений.

Если значения совпадают — строки получают одинаковый ранг, а следующий ранг пропускается.

Пример результата:

1
2
2
4

Пример использования:

`RANK() OVER (ORDER BY salary DESC)`

Часто используется для:

— рейтингов
— соревнований
— аналитики продаж

---------------------------------------------------------------------------------------------

DENSE_RANK()

Работает почти как RANK(), но без пропусков в рангах.

Пример результата:

1
2
2
3

Пример:

`DENSE_RANK() OVER (ORDER BY salary DESC)`

Это удобно, когда важно понимать реальное количество уровней ранга.

---------------------------------------------------------------------------------------------

NTILE()

Разбивает строки на N групп.

Пример:

`NTILE(4) OVER (ORDER BY salary)`

Данные будут разбиты на 4 группы примерно одинакового размера.

Где применяется:

— квартели
— перцентили
— сегментация пользователей
— распределение данных по группам

---------------------------------------------------------------------------------------------

💡 Коротко о разнице функций

ROW_NUMBER()
— просто нумерация строк

RANK()
— одинаковые значения получают одинаковый ранг, но есть пропуски

DENSE_RANK()
— одинаковые значения получают одинаковый ранг без пропусков

NTILE()
— делит строки на группы

---------------------------------------------------------------------------------------------

Оконные функции ранжирования — один из самых полезных инструментов SQL-аналитики.
С их помощью легко строить рейтинги, топы, сегментации и распределения прямо в запросе.

354 миллиона рублей на Postgres в России: стоит ли учить эту СУБД прямо сейчас?

Ловите новость, которая напрямую отвечает на вопрос "Актуален ли PostgreSQL на российском рынке?".

Правительство Ленинградской области объявило масштабную закупку на импортозамещение баз данных. Цифры, от которых у разработчиков и администраторов БД загораются глаза:

Бюджет контракта: около 354 млн рублей

Объем: не менее 2300 лицензий СУБД Postgres Pro

Срок: внедрение до 2028 года в системах органов власти

Перед нами не просто очередная новость, а маркер того, куда движется рынок. Postgres Pro — это сертифицированная отечественная сборка на базе знакомого нам всем PostgreSQL. Государство выбирает этот стек как стандарт.

А теперь включаем режим турбо и думаем, что это значит для нас:

Рынку нужны люди. 2300 лицензий — это новые рабочих места. Кто-то должен эти базы ставить, настраивать, мигрировать на них данные с устаревших систем, а потом администрировать и разрабатывать под них запросы. Это не абстрактные вакансии, а вполне конкретные задачи с понятным горизонтом планирования до 2028 года.

PostgreSQL становится стандартом. Если государство (а за ним потянутся и госкорпорации, и крупный бизнес) массово переходит на PostgreSQL, значит, знание этой СУБД переходит из категории "плюшек" в категорию "must have". Для администраторов БД, разработчиков 1С, аналитиков данных — это базовый инструмент.

Импортозамещение = рабочие места. Проекты с бюджетами в сотни миллионов рублей не делаются "на коленке". Им нужны квалифицированные кадры. Специалисты, которые умеют работать с PostgreSQL на серьезном уровне (производительность, отказоустойчивость, миграция с Oracle/MSSQL), сейчас входят в золотую лигу.

Мой вывод:

Если вы выбираете, какую навык сейчас учить — PostgreSQL это очевидный выбор номер один. Это не просто "еще один инструмент в резюме", это прямой билет в крупные проекты с госфинансированием и реальные промышленные задачи.

Вчера на PG BootCamp Russia 2026 👨‍💻

Съездил, посмотрел, послушал. Пост-впечатление без воды.

Что круто:
— Доклады реально про пользу. Никакой воды, всё по делу: про производительность, про масштабирование, про подводные камни в продвинутых сценариях.
— Атмосфера камерная, но при этом много крутых спикеров. Можно было что то спросить, подискутировать. В этом формате это особенно ценно.
— Постгрес-сообщество живёт и активно развивается. Приятно видеть, сколько людей реально горят темой.

Коротко: не зря съездил. Вдохновение + новые идеи + знакомства.

Кстати, заметил, что сейчас всё больше разговоров про оптимизацию и про работу с данными в промышленных масштабах. Значит, направление выбрано правильно.

Ну и классика: сфоткался на фоне стенда 😎

Как я узнал, что PostgreSQL можно ускорить с помощью квантового компьютера (и это не шутка).

Сижу, листаю научные статьи (да, бывает и такое). И тут натыкаюсь на работу, где ребята реально подключили PostgreSQL к гибридному квантово-классическому солверу D-Wave.

Сначала подумал: очередная теория для конференций. А потом вчитался — и понял, что это реальный эксперимент с работающим прототипом.

Они взяли PostgreSQL 16.4, добавили pg_hint_plan (чтоб управлять порядком JOIN-ов), а вместо стандартного оптимизатора использовали гибридный квантово-классический подход: классическая часть собирает статистику (кардинальность, селективность), а квантовая решает комбинаторную задачу выбора оптимального порядка JOIN.

И знаете что?

На тестовых запросах (Join Order Benchmark) они получили:

Ускорение выполнения запросов до 92.7%

Один запрос, который выполнялся 3.5 секунды, стал отрабатывать за 0.27 секунды

Даже с учётом того, что запрос улетал в облако D-Wave (2.5–2.8 секунды туда-обратно), общее время сократилось в 1.4 раза

И главное — они сделали то, что никто до них вероятно не делал:

Поддержали bushy join trees (это когда можно джойнить не только линейно, а по-хитрому)

Не ограничились 5 таблицами, как в предыдущих попытках, а дошли до 17.

Встроили это в реальную базу, а не просто посчитали на симуляторе

Да, накладные расходы пока высокие — 2–3 секунды на вызов квантового солвера. Для простых запросов это не нужно. А вот для сложных аналитических, где обычный PostgreSQL иногда работает долго и выбирает неоптимальный план — разница может быть драматичной.

Авторы честно признают: не все 113 запросов ускорились. Но там, где ускорились — прирост колоссальный. А там, где не ускорились, деградация в среднем всего 11%. И 20% запросов получили bushy-планы, которые стандартный планировщик даже не рассматривал.

Честно, я сначала отнёсся скептически. Но когда увидел цифры и то, что они реально подняли это на PostgreSQL — стало интересно.

Квантовые вычисления в базах данных — это уже не "через 20 лет". Это уже сейчас, на реальных серверах, с реальным кодом, в гибридном формате, где квантовая часть помогает классическому оптимизатору там, где он справляется хуже.



P.S. Статья называется "Hybrid quantum–classical optimization for bushy join trees in PostgreSQL".

Привет, друзья!

Сегодня разберём одну тему, которая вроде бы “ну что там сложного”,
но на практике стабильно даёт ошибки даже тем, кто уже работает с SQL.

Речь снова про GROUP BY.
Но не в общем, а через конкретные косяки, которые встречаются постоянно.

❌ Ошибка №1. “Добавлю колонку в SELECT — база сама разберётся”

Пишешь такой запрос:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY customer_id;

И получаешь ошибку.

("Ну я же просто добавил поле, в чём проблема?")

А проблема в том, что после GROUP BY у тебя уже другой уровень данных:

👉 одна строка = один customer_id

А order_date — это уже деталь внутри группы.
И база такая: “Я не понимаю, какую дату тебе показать”

👉 первую? последнюю? случайную?

Поэтому правило:

либо агрегируй (MIN, MAX), либо не трогай

("База не угадывает твои мысли, ей нужно чёткое указание")

❌ Ошибка №2. Путаница WHERE и HAVING

Классика, которую вижу постоянно.

SELECT customer_id, SUM(amount)
FROM orders
WHERE SUM(amount) > 1000
GROUP BY customer_id;

Так не работает.

Почему?

👉 WHERE применяется до группировки
👉 А SUM(amount) появляется после

То есть ты фильтруешь то, чего ещё не существует.

Правильно:

SELECT customer_id, SUM(amount)
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000;

Запомни простую мысль:

👉 WHERE — фильтрует строки
👉 HAVING — фильтрует группы

❌ Ошибка №3. “Сгруппирую по имени клиента — и норм”

Очень коварная штука.

GROUP BY customer_name

Выглядит логично.
Но потом начинается магия:

два “Ивана Иванова” → одна строка
один и тот же клиент с разным написанием → две строки

👉 Итог: кривая аналитика

Правильный подход:

GROUP BY customer_id

А имя уже можно подтянуть отдельно.

("Группируем по идентификаторам, а не по тому, как это красиво выглядит")

Итог:

GROUP BY — это не просто “собрать строки вместе”.

И кстати 👇

В будущей версии PostgreSQL 19 появится интересная штука — GROUP BY ALL.

Смысл простой:

👉 база сама подставит в GROUP BY все неагрегированные поля из SELECT

То есть вместо:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY customer_id, order_date;

можно будет написать:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY ALL;

Удобно? Да.
Но расслабляться не стоит 🙂

("Если не понимаешь, что группируешь — никакой ALL не спасёт")

Зачем писать LIKE там, где нужно просто =?

Заметил: многие сравнивают строки через LIKE даже тогда, когда ищут точное совпадение.

Вот так:

SELECT *
FROM orders o
WHERE customer_id LIKE 'ALFKI';

Или еще хуже вот так:

SELECT *
FROM orders o
WHERE customer_id LIKE '%ALFKI%';

Хотя можно было вот так:

SELECT *
FROM orders o
WHERE customer_id = 'ALFKI';

Это работает. Но:

Индекс не используется (или используется неэффективно). На = индекс отработает идеально. На LIKE с константой и % — нет.

Читается тяжелее. Глаз цепляется за LIKE и думает: "Там точно какой-то поиск по шаблону". А на самом деле нет.

Привычка, которая выстрелит в спину. Однажды ты напишешь LIKE '%значение' — и запрос упадёт по производительности. А ты и не заметишь, потому что привык.

LIKE нужен для поиска по шаблону, который задает искомые символы или комбинации, а для констант нужно просто =.

Это как забивать гвозди микроскопом. Микроскоп классный, но молоток лучше.