7786
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it
☕️ StrataScratch — вопросы с собеседований!
Готовишься к собеседованиям по SQL или хочешь укрепить свои практические навыки? Этот сайт собрал самые важные вопросы, которые реально встречаются на интервью. Здесь есть и запросы на выборки, агрегаты и JOIN, и открытые задачи, где нужно не просто написать код, а объяснить логику решения.
📌 Оставляю ссылочку: stratascratch.com
➡️ SQL Ready | #ресурс
📂 Напоминалка по SQL Injection (SQLi)!
Например, простая инъекция вроде OR 1=1 может вернуть все данные из таблицы, а blind SQLi позволяет вытаскивать информацию даже тогда, когда приложение не показывает ошибки и результаты запросов.
На картинке — основные типы SQL-инъекций, которые важно знать при работе с базами данных и backend-логикой.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс
NULL и NOT IN — тонкость SQL, приводящая к логическим ошибкам!
При использовании NOT IN в SQL можно получить логически неверный результат без ошибок выполнения. Причина — трёхзначная логика и наличие NULL в данных.
Представим таблицы:
customers(id)
orders(id, customer_id)
SELECT id
FROM customers
WHERE id NOT IN (
SELECT customer_id
FROM orders
);
NULL, результат этого запроса будет пустым, даже если клиенты без заказов существуют.NOT IN сводится к серии сравнений, а любое сравнение с NULL возвращает неопределённый результат.SELECT id
FROM customers
WHERE id NOT IN (
SELECT customer_id
FROM orders
WHERE customer_id IS NOT NULL
);
NOT EXISTS:SELECT c.id
FROM customers c
WHERE NOT EXISTS (
SELECT 1
FROM orders o
WHERE o.customer_id = c.id
);
NOT EXISTS корректно обрабатывает NULL и предназначен именно для проверок отсутствия связанных строк.NOT EXISTS для анти-джойнов и проверок отсутствия данных, а NOT IN — только при полном контроле результата подзапроса.
📂 Напоминалка по масштабированию баз данных!
Например, индексы ускоряют поиск данных, кэш снижает нагрузку на базу, а шардинг позволяет распределять данные между серверами.
На картинке — 10 техник масштабирования БД, которые стоит держать под рукой при работе с высокими нагрузками.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс
😎 SQL Style Guide — супер полезный репозиторий для освоения языка!
Практичный ресурс по написанию SQL: как оформлять SELECT, JOIN, CTE, подзапросы и имена таблиц, чтобы запросы были понятными, поддерживаемыми и удобными для работы в команде. Подходит для любых СУБД и реально упрощает работу и учебу.
Оставляю ссылочку: GitHub 📱
Как корректно сравнивать значения с NULL?
Обычное сравнение может сломаться, когда в данных появляется NULL. В SQL выражение:
email <> 'admin@example.com'
email IS DISTINCT FROM 'admin@example.com'
old_value IS DISTINCT FROM new_value
📂 Напоминалка по структурам данных для экономии памяти и работы с большими данными!
Например, Bloom Filter позволяет быстро проверить, встречался ли элемент ранее, а HyperLogLog помогает оценить количество уникальных значений, не храня все данные целиком.
На картинке — 6 структур данных, которые стоит держать под рукой при проектировании backend-систем, аналитики и highload-сервисов.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс
Префиксные индексы в MySQL — ускоряем поиск по длинным строкам!
Полные индексы на длинных строках занимают много ресурсов, тогда как префиксные индексируют только первые N символов, уменьшая объём индекса и ускоряя поиск при высокой селективности начала строки.
Создадим таблицу с длинным текстовым атрибутом — типичный кейс, где полный индекс был бы слишком тяжёлым:
CREATE TABLE documents (
id INT PRIMARY KEY,
doc_key VARCHAR(500) NOT NULL
);
CREATE INDEX idx_doc_key_prefix
ON documents (doc_key(20));
SELECT id
FROM documents
WHERE doc_key LIKE 'INV-2024-%';
CREATE INDEX idx_email_prefix
ON users (email(16));
Почему 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 может перестать читать таблицу.
📂 Напоминалка для работы с индексами в базах данных!
Например, B+ Tree Index используется для быстрого поиска и сортировки, а Hash Index подходит для точных совпадений по ключу.
На картинке — 5 основных структур данных, на которых строятся индексы в современных СУБД.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс
Забудь про ChatGPT. Это как просить калькулятор нарисовать картину.
Пока массы гоняют одни и те же скучные запросы в зацензуренные боты, реальная революция ИИ в канале «Техноразум»:
— Нейросети, которые не боятся запретных тем ( 🔞)
— Скрытые функции, которые другие ИИ прячут за платную подписку или цензурой
— Настоящие инструкции и промты для взлома творческих шаблонов
Переходи к настоящим возможностям, забудь про детский сад нейросетей: /channel/+7dOPAyODQ6
Почему ваше резюме попадает в папку «Отказы»?
На картинке вы видите 295 отказов.
Среднестатистический соискатель думает: «Нужно лучше составить резюме» или «У меня мало опыта».
Рекрутер видит другое: 295 ошибок.
❌ Неправильно выбранная стратегия откликов.
❌ Ключевые слова, которые не видит система ATS.
❌ Отклик на ФЕЙКОВЫЕ вакансии.
Работодатели не будут учить вас, как проходить их собственные фильтры. Это не в их интересах. Но это в наших интересах.
Мы — @Mathcareer — знаем систему изнутри.
Хотите узнать, что на самом деле скрывается за отказами и как это исправить? Подписывайтесь: /channel/+erDge2ZLK4BmM2Ri
🖥 Как восстановить пользовательские сессии без session_id?
SQL позволяет восстановить сессии даже без session_id, выделяя их по временным разрывам и последовательности событий.
Сегодня в задаче:
• Определим моменты, когда начинается новая сессия;
• Присвоим каждому событию уникальный session_id с помощью оконной суммы;
• Получим полноценные сессии так же, как это делают продуктовые аналитические платформы.
Работа со строками в PostgreSQL — извлекаем данные с помощью регулярных выражений!
В аналитике часто нужно разобрать строку: вытащить домен из email, код из SKU, номер из текста. PostgreSQL предоставляет функции regexp_match и regexp_replace, позволяющие делать это напрямую в SQL.
Создадим таблицу:
CREATE TABLE users (
id INT,
email TEXT,
profile_code TEXT
);
SELECT
id,
email,
(regexp_match(email, '@(.+)$'))[1] AS domain
FROM users;
regexp_match возвращает один массив, и [1] достаёт первую группу. Паттерн @(.+)$ берёт всё, что стоит после символа @.USR-2391-A":SELECT
id,
profile_code,
(regexp_match(profile_code, '([0-9]+)'))[1] AS numeric_part
FROM users;
([0-9]+) извлекает последовательность цифр.SELECT
id,
regexp_replace(profile_code, '[^A-Za-z0-9]', '', 'g') AS cleaned
FROM users;
Как точечно понять, почему конкретный индекс НЕ используется оптимизатором?
Если запрос игнорирует индекс, причина может быть не в индексе, а в том, что PostgreSQL не знает, насколько селективное значение в колонке.
Обновить статистику можно точечно, для одной конкретной колонки:
ANALYZE users (status);
Index Scan.ALTER TABLE users
ALTER COLUMN status SET STATISTICS 500;
Как понять, что PostgreSQL работает на устаревшей статистике?
PostgreSQL хранит информацию о последнем сборе статистики:
SELECT relname,
last_analyze,
last_autoanalyze,
n_live_tup
FROM pg_stat_user_tables;
last_analyze — когда статистика обновлялась вручную,last_autoanalyze — когда это делал autovacuum.SELECT relname,
n_live_tup,
last_analyze,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;
last_analyze — оптимизатор работает вслепую.ANALYZE;
ANALYZE orders;
🖥 Ищем клиентов без единого заказа — полезный приём для выявления неактивных пользователей и повышения конверсии!
Цель — найти всех зарегистрированных пользователей, которые так и не оформили ни одного заказа. Это поможет вернуться к ним с акциями или напоминаниями.
Основные моменты:
• LEFT JOIN — соединяем таблицы, чтобы сохранить всех клиентов, даже тех, у кого нет заказов.
• WHERE o,id IS NULL — отбираем только тех, для кого заказов не найдено.
• SELECT — выводим имя, email и дату регистрации.
Условный UPSERT: как не обновлять строки без изменений?
Обычный UPSERT обновляет строку всегда, даже если данные не изменились — это лишние блокировки, WAL и autovacuum.
PostgreSQL позволяет сделать условный UPDATE прямо в ON CONFLICT:
ON CONFLICT (id) DO UPDATE
...
WHERE users.email IS DISTINCT FROM EXCLUDED.email
OR users.name IS DISTINCT FROM EXCLUDED.name;
UPDATE не выполняется вообще.EXCLUDED — это “новая” версия строки, users.* — текущая версия в таблице.users.col IS DISTINCT FROM EXCLUDED.col
NULL и не попадает в ловушки трёхзначной логики.
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.
🖥 GROUPING SETS — несколько отчётов в одном запросе!
В аналитике часто нужно считать данные сразу на нескольких уровнях: детализация, промежуточные итоги и общий результат. GROUPING SETS позволяет описать эту структуру напрямую.
Сегодня в гайде:
• Как считать несколько уровней агрегации за один проход по данным;
• Как отличать строки-итоги от обычных данных;
• Почему такой подход проще поддерживать и масштабировать.
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;
GROUP BY. В зависимости от СУБД и режима он либо не выполнится, либо вернёт неопределённый результат.SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id;
DISTINCT для простого удаления дублей, а GROUP BY — когда нужна агрегация, расчёты по группам или HAVING.
Как избежать блокировок таблиц с помощью 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);
COMMIT или ROLLBACK блокировка снимается автоматически.
❤️ SQL-101 — руководство, помогающее освоить язык и укрепить базу тем, кто уже работает с БД.
В этом ресурсе собраны ключевые темы, которые нужны в работе: базовые запросы, фильтрация, JOIN, группировки, подзапросы, индексы, транзакции и основы оптимизации. Всё объяснено простым языком и дополнено примерами с упражнениями.
Оставляю ссылочку: Github 📱
⚡️ ВАЙБ-КОДИНГ теперь в Telegram!
Ребята сделали крутейший канал, где на наглядных примерах и понятном языке рассказывают как войти в новую эру разработки с ИИ, делятся полезными фишками и инструментами
Подписывайтесь, нас уже 10 тысяч: @vibecoding_tg
Как понять, какие индексы только тратят место?
Ненужные индексы замедляют вставки, обновления и 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;
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
)
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;
id < last_seen_id.last_seen_id для следующего запроса.
✍️ LangShift — учись новому языку программирования, используя знания, которые у тебя уже есть!
Этот сайт предлагает другой путь: выбираешь язык, который уже знаешь, и переходишь на новый через сопоставление синтаксиса и парадигм. Более 80 модулей, 30+ проектов, всё бесплатно и без регистрации.
📌 Оставляю ссылочку: langshift.dev
➡️ SQL Ready | #ресурс
😎 На Хабре вышла полезная статья: «6 лайфхаков при внедрении СУБД: учимся на чужих граблях»!
В этой статье:• Разберёте реальные ошибки при развёртывании СУБД;
• Узнаете, как повысить производительность запросов через правильное партицирование и не только;
• Поймёте, как организовать конкурентный доступ и обновления данных без блокировок и простоев;
• Получите шесть конкретных лайфхаков, которые помогут избежать критических проблем.
🔊 Продолжайте читать на Habr!
😎 Sqltest - бесплатный онлайн-тренажёр для практики запросов прямо в браузере!
Вам будут доступы более 320 интерактивных задач разной сложности: от простых SELECT-запросов до вложенных подзапросов и агрегаций. Поддерживаются MySQL, PostgreSQL, MS SQL и Firebird, есть мгновенная проверка решений и удобный интерфейс для отработки навыков на практике.
📌 Оставляю ссылочку: sqltest.online
➡️ SQL Ready | #ресурс
📂 Напоминалка по оптимизации производительности БД!
Например, грамотное индексирование ускоряет выборки в разы, шардирование помогает масштабировать систему под высокий трафик, а репликация повышает отказоустойчивость и снижает нагрузку на основной узел.
На изображении — структурированное напоминание о ключевых метриках, типах нагрузок и практических стратегиях оптимизации.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс