SQL Ready | Базы Данных

FILTER в агрегатных функциях PostgreSQL! В аналитических запросах часто нужно посчитать несколько показателей из одной таблицы. В PostgreSQL для этого есть FILTER, позволяющий задавать условия отдельно для каждой агрегатной функции, не влияя на весь запрос. Представим таблицу заказов:

orders(id, customer_id, amount, status)

Посчитаем общее количество заказов и количество завершённых:

SELECT
    COUNT(*) AS total_orders,
    COUNT(*) FILTER (WHERE status = 'completed') AS completed_orders
FROM orders;

FILTER применяется непосредственно к агрегатной функции и ограничивает только те строки, которые участвуют в её расчёте. Добавим несколько метрик в одном запросе:

SELECT
    COUNT(*) AS total_orders,
    COUNT(*) FILTER (WHERE status = 'completed') AS completed_orders,
    COUNT(*) FILTER (WHERE status = 'canceled')  AS canceled_orders,
    SUM(amount) FILTER (WHERE status = 'completed') AS completed_amount
FROM orders;

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

AVG(amount) FILTER (WHERE status = 'completed')
MAX(amount) FILTER (WHERE status = 'completed')
MIN(amount) FILTER (WHERE status = 'completed')

🔥 Важно помнить: FILTER работает только с агрегатными функциями и применяется внутри SELECT, дополняя, а не заменяя WHERE и GROUP BY. ➡️ SQL Ready | #практика

👩‍💻 Программирование — В С Ё В 2025 году на кодинге уже не вывезешь, перспектива года - Информационная Безопасность. Ловите полезные каналы, которые помогут ворваться в новое направление. 👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля 👍 Белый Хакер — Свежие новости из мира ИБ 😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг 👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям 📂 Вступай и изучай новое направление!

😎 SQL Style Guide — супер полезный репозиторий для освоения языка! Практичный ресурс по написанию SQL: как оформлять SELECT, JOIN, CTE, подзапросы и имена таблиц, чтобы запросы были понятными, поддерживаемыми и удобными для работы в команде. Подходит для любых СУБД и реально упрощает работу и учебу.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

🖥 GROUPING SETS — несколько отчётов в одном запросе! В аналитике часто нужно считать данные сразу на нескольких уровнях: детализация, промежуточные итоги и общий результат. GROUPING SETS позволяет описать эту структуру напрямую. Сегодня в гайде:

• Как считать несколько уровней агрегации за один проход по данным; • Как отличать строки-итоги от обычных данных; • Почему такой подход проще поддерживать и масштабировать.

Приём, который делает отчёты чище, быстрее и предсказуемее при росте требований. ➡️ SQL Ready | #гайд

Ищу 10 человек, чтобы собирали чат-ботов по шаблону, как пазлы. ЗП: от 5-9000₽ за вечер. Занятость: 3-4 часа в день. Опыт: не нужен. Как мы работаем: 1. Ты проходишь обучение пару недель; 2. Берёшь реальный проект из моей базы; 3. Собираешь бота по проверенной формуле; 4. Наставник контролирует процесс; 5. Получаешь деньги и закрепляешь клиента. Весь процесс занимает до 2х недель с нуля до первых денег на твою карту. Даниил из Балашихи был военнослужащим — с июля 2024 года начал создавать чат-ботов для бизнеса и уже заработал 4 млн. рублей. А главное теперь у него больше свободного времени на семью, друзей и развлечения. Да, ты не первый. 103 человека уже ведут постоянных клиентов по моей формуле. Ведь сайт со статистикой Wordstat показывает 10 786 запросов за месяц в поисковике от бизнеса на эту услугу. Заказов валом. Срочно нужны твои руки и голова. Чтобы быстро разобраться во всех нюансах — запускай бота Там пошаговый план как стартануть и гайд по клиентам. 8 мест ещё свободно

Как корректно сравнивать значения с NULL? Обычное сравнение может сломаться, когда в данных появляется NULL. В SQL выражение:

email <> 'admin@example.com'

не вернёт строки с email IS NULL — результат будет UNKNOWN. Для корректного сравнения используйте IS DISTINCT FROM:

email IS DISTINCT FROM 'admin@example.com'

Оно работает так, как ожидаешь: NULL ≠ любое значение NULL = NULL Результат всегда TRUE или FALSE (без UNKNOWN). То же самое для проверки изменений:

old_value IS DISTINCT FROM new_value

🔥 Это инструмент не для синтаксиса, а для корректности данных. ➡️ SQL Ready | #совет

DISTINCT vs GROUP BY — выбираем правильный инструмент для удаления дублей! В SQL часто нужно избавиться от повторяющихся строк: уникальные пользователи, товары, категории. Для этого используют DISTINCT и GROUP BY. Результат может выглядеть одинаково, но назначение и смысл у этих конструкций разные. Представим таблицу заказов:

orders(id, customer_id, product_id)

Найдём всех уникальных клиентов, которые делали заказы:

SELECT DISTINCT customer_id
FROM orders;

DISTINCT удаляет дубликаты по всему набору выбранных колонок в результирующем наборе — без группировок и агрегаций. Сделаем то же самое через GROUP BY:

SELECT customer_id
FROM orders
GROUP BY customer_id;

Результат будет тем же, но семантически запрос другой: явно группируем строки по customer_id. В простых случаях оптимизатор часто строит одинаковый план, но логика запроса уже «про группы». GROUP BY становится необходимым, когда появляются агрегаты. Посчитаем количество заказов на каждого клиента:

SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id;

В этом запросе GROUP BY обязателен, потому что мы одновременно выбираем агрегат (COUNT(*)) и неагрегированное поле (customer_id). Частая ошибка — смешивать DISTINCT и агрегаты без GROUP BY:

SELECT DISTINCT customer_id, COUNT(*)
FROM orders;

Такой запрос в стандартном SQL некорректен: неагрегированные поля должны присутствовать в GROUP BY. В зависимости от СУБД и режима он либо не выполнится, либо вернёт неопределённый результат. Корректный вариант:

SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id;

🔥 Используй DISTINCT для простого удаления дублей, а GROUP BY — когда нужна агрегация, расчёты по группам или HAVING. ➡️ SQL Ready | #практика

👩‍💻 В сеть вывалилась гигантская куча курсов и книг от топовых IT‑школ Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё! • 1612 ГБ — DevOps • 1402 ГБ — Python • 1300 ГБ — C, C++ • 1815 ГБ — Frontend • 1515 ГБ — Backend • 898 ГБ — ИБ, Хакинг • 996 ГБ — Kotlin, Swift • 212 ГБ — JavaScript • 315 ГБ — Flutter • 820 ГБ — Go, PHP • 419 ГБ — Java, Rust • 648 ГБ — GameDev • 517 ГБ — Windows, Linux • 998 ГБ — Дизайн (UX/UI) • 617 ГБ — Нейросети (ML/RL) • 546 ГБ — БД (SQL & NoSQL) • 687 ГБ — Аналитика данных • 115 ГБ — QA-тестирование Подписывайся и не плати за то, что можно получить бесплатно

📂 Напоминалка по структурам данных для экономии памяти и работы с большими данными! Например, Bloom Filter позволяет быстро проверить, встречался ли элемент ранее, а HyperLogLog помогает оценить количество уникальных значений, не храня все данные целиком. На картинке — 6 структур данных, которые стоит держать под рукой при проектировании backend-систем, аналитики и highload-сервисов. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

Как избежать блокировок таблиц с помощью advisory locks в PostgreSQL! Иногда нужно гарантировать, что только один процесс выполняет критическую секцию, но при этом не хочется блокировать таблицы и строки. Для этого PostgreSQL предоставляет advisory locks — логические блокировки, не привязанные к таблицам или строкам.

SELECT pg_advisory_xact_lock(42);

Пока транзакция активна, другие процессы с тем же ключом будут ожидать. Ключ — это просто число. Можно использовать user_id, order_id, хеш или tenant_id.

SELECT pg_advisory_xact_lock(user_id);

🔥 Это превращает PostgreSQL в механизм распределённой синхронизации. После COMMIT или ROLLBACK блокировка снимается автоматически. ➡️ SQL Ready | #совет

Префиксные индексы в MySQL — ускоряем поиск по длинным строкам! Полные индексы на длинных строках занимают много ресурсов, тогда как префиксные индексируют только первые N символов, уменьшая объём индекса и ускоряя поиск при высокой селективности начала строки. Создадим таблицу с длинным текстовым атрибутом — типичный кейс, где полный индекс был бы слишком тяжёлым:

CREATE TABLE documents (
    id INT PRIMARY KEY,
    doc_key VARCHAR(500) NOT NULL
);

Добавим префиксный индекс. Индексируются только первые 20 символов:

CREATE INDEX idx_doc_key_prefix
ON documents (doc_key(20));

Если фильтровать данные по фиксированному началу строки, MySQL использует префиксный индекс:

SELECT id
FROM documents
WHERE doc_key LIKE 'INV-2024-%';

Важно: индекс применяется только если шаблон начинается без ведущего %. Например, LIKE '%2024%' уже не сможет его использовать. Пример с email — если полная индексация не нужна:

CREATE INDEX idx_email_prefix
ON users (email(16));

🔥 Ограничения: префикс должен быть достаточно селективным, иначе польза минимальна. Такие индексы практически не подходят для сортировки или группировки по полному полю, так как индекс содержит лишь его часть. ➡️ SQL Ready | #практика

Индийский хакер Чиккен Тика Масала взломал GPT 5.0 и снял все внутренние ограничения Индус настроил GPT под любые задачи, начиная от взлома аккаунтов до изготовления оружия. В своём блоге «Only GPT» он публикует все найденные баги и фичи, пока разрабы их не прикрыли: — Как пользоваться Veo 3 и другими видео-генераторами бесплатно — Как генерить фото 18+ в Midjourney — Отключение ограничений в Gemini, GPT и Perplexity Секретные рецепты и промты индуса собраны здесь — @onlygpt 🤫

❤️ SQL-101 — руководство, помогающее освоить язык и укрепить базу тем, кто уже работает с БД. В этом ресурсе собраны ключевые темы, которые нужны в работе: базовые запросы, фильтрация, JOIN, группировки, подзапросы, индексы, транзакции и основы оптимизации. Всё объяснено простым языком и дополнено примерами с упражнениями.

Оставляю ссылочку: Github 📱

➡️ SQL Ready | #репозиторий

Почему Index Only Scan в PostgreSQL не всегда работает? Если PostgreSQL не использует Index Only Scan, проблема часто не в запросе и не в самом индексе. Index Only Scan работает только если страницы помечены как видимые в visibility map. Если этого нет PostgreSQL всё равно идёт в таблицу. Проверьте план выполнения:

EXPLAIN ANALYZE
SELECT id FROM orders WHERE status = 'pending';

Если видите Index Scan, а не Index Only Scan, одна из частых причин в том, что visibility map не заполнена (при наличии подходящего covering index). Исправляется простой командой:

VACUUM (ANALYZE) orders;

🔥 VACUUM помечает страницы как all-visible, и PostgreSQL может перестать читать таблицу. ➡️ SQL Ready | #совет

⚡️ ВАЙБ-КОДИНГ теперь в Telegram! Ребята сделали крутейший канал, где на наглядных примерах и понятном языке рассказывают как войти в новую эру разработки с ИИ, делятся полезными фишками и инструментами Подписывайтесь, нас уже 10 тысяч: @vibecoding_tg

📂 Напоминалка для работы с индексами в базах данных! Например, B+ Tree Index используется для быстрого поиска и сортировки, а Hash Index подходит для точных совпадений по ключу. На картинке — 5 основных структур данных, на которых строятся индексы в современных СУБД. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

Как понять, какие индексы только тратят место? Ненужные индексы замедляют вставки, обновления и VACUUM. PostgreSQL умеет показать, какие индексы ни разу не использовались. Посмотрим статистику использования:

SELECT relname, idx_scan, pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

idx_scan = 0 — индекс ни разу не участвовал в плане. size покажет, сколько места он занимает на диске. Нужно увидеть “почти бесполезные” индексы? С сортировкой по минимальному использованию:

SELECT relname, idx_scan, idx_tup_read
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC
LIMIT 10;

🔥 Инструмент позволяет быстро уменьшить нагрузку, ускорить записи и освободить место. ➡️ SQL Ready | #совет

Забудь про ChatGPT. Это как просить калькулятор нарисовать картину. Пока массы гоняют одни и те же скучные запросы в зацензуренные боты, реальная революция ИИ в канале «Техноразум»: — Нейросети, которые не боятся запретных тем ( 🔞) — Скрытые функции, которые другие ИИ прячут за платную подписку или цензурой — Настоящие инструкции и промты для взлома творческих шаблонов Переходи к настоящим возможностям, забудь про детский сад нейросетей: https://t.me/+7dOPAyODQ6

Keyset-пагинация: быстрый скролл без OFFSET! OFFSET…LIMIT прост, но плохо масштабируется: чем дальше страница, тем медленнее запрос и выше риск дубликатов при вставках. Keyset использует курсор (id/дату) и даёт стабильную скорость на больших объёмах. Создаём таблицу (пример на PostgreSQL):

CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Подготавливаем входящие данные с помощью CTE:

WITH cursor AS (
    SELECT 1000::BIGINT AS last_seen_id
)

Здесь мы храним «курсор» — id последней записи, которую клиент уже получил. Получаем следующую страницу без OFFSET по keyset-подходу:

SELECT p.id, p.title, p.created_at
FROM posts p
JOIN cursor c ON TRUE
WHERE p.id < c.last_seen_id
ORDER BY p.id DESC
LIMIT 20;

Запрос отдаёт следующие 20 записей с id < last_seen_id. На клиенте берём минимальный id из результата и используем его как новый last_seen_id для следующего запроса. 🔥 Подход работает в PostgreSQL, MySQL, SQL Server и др.: стабильно, эффективно и без проблем с дубликатами при конкурентных вставках. ➡️ SQL Ready | #практика