SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_c РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
Show more📈 Analytical overview of Telegram channel SQL Ready | Базы Данных
Channel SQL Ready | Базы Данных (@sql_ready) in the Russian language segment is an active participant. Currently, the community unites 16 623 subscribers, ranking 7 623 in the Technologies & Applications category and 39 659 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 16 623 subscribers.
According to the latest data from 02 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 1 250 over the last 30 days and by 14 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 12.44%. Within the first 24 hours after publication, content typically collects 6.20% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 068 views. Within the first day, a publication typically gains 1 031 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 24.
- Thematic interests: Content is focused on key topics such as sql, строка, users, индекс, user_id.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_c
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
Thanks to the high frequency of updates (latest data received on 03 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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 | #совет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 | #практика• Определим моменты, когда начинается новая сессия; • Присвоим каждому событию уникальный session_id с помощью оконной суммы; • Получим полноценные сессии так же, как это делают продуктовые аналитические платформы.Пригодится для расчёта удержания, построения пользовательских путей, анализа фич и диагностики проблем поведения. ➡️ SQL Ready | #задача
• Разберёте реальные ошибки при развёртывании СУБД;
• Узнаете, как повысить производительность запросов через правильное партицирование и не только;
• Поймёте, как организовать конкурентный доступ и обновления данных без блокировок и простоев;
• Получите шесть конкретных лайфхаков, которые помогут избежать критических проблем.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
regexp_match и regexp_replace, позволяющие делать это напрямую в SQL.
Создадим таблицу:
CREATE TABLE users (
id INT,
email TEXT,
profile_code TEXT
);
Извлечём домен из email:
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;
🔥 Такие операции часто используются при подготовке данных, парсинге логов, анализе текстовых полей и нормализации входных атрибутов.
➡️ SQL Ready | #практикаPostgreSQL не знает, насколько селективное значение в колонке.
Обновить статистику можно точечно, для одной конкретной колонки:
ANALYZE users (status);
Теперь оптимизатор видит реальное распределение значений и может корректно выбрать Index Scan.
Хотите повысить точность — увеличьте глубину сбора статистики:
ALTER TABLE users
ALTER COLUMN status SET STATISTICS 500;
🔥 Позволяет понять почему план деградирует и как вернуть индекс в работу, без изменения кода и структуры данных.
➡️ SQL Ready | #совет📌 Инструменты, гайды, шпаргалки практические гайды.
SELECT с результатами второго SELECT из подзапроса, что может быть удобно в некоторых случаях: если подзапрос возвращает небольшое количество строк или когда нужно сравнить значение хотя бы с одним значением из подзапроса.
Представим, что нам нужно найти все продукты, цена которых выше, чем цена любого продукта в категории Discount:
SELECT product, price
FROM products
WHERE price > ALL (SELECT price FROM products WHERE category = 'Discount');
Теперь найдем всех клиентов, заказавших хотя бы один продукт с ценой выше 1000 рублей:
SELECT DISTINCT customer_id
FROM orders
WHERE product_id = ANY (SELECT product_id FROM products WHERE price > 1000);
И найдем всех клиентов, которые заказывали продукты из определенной категории:
SELECT DISTINCT customer_id
FROM orders
WHERE product_id = ANY (SELECT product_id FROM products WHERE category = 'Electronics');
🔥 Но помните, что использование ALL и ANY возможно только с подзапросами и может быть неэффективным, если подзапрос возвращает большое количество строк.
➡️ SQL Ready | #практикаUX определяется не средним временем ответа, а редкими хвостовыми задержками, из-за которых важны именно p95 и p99.
Сегодня в задаче:
• Посчитаем ключевые перцентильные метрики (p50/p95/p99) по каждому маршруту; • Определим, какие запросы регулярно превышают собственный p99; • Увидим, какие эндпоинты “убивают” отклик сервиса под нагрузкой;Такой анализ помогает быстро находить узкие места
API и контролировать качество работы системы.
➡️ SQL Ready | #задачаRETURNING позволяет вернуть значения вставленных, обновлённых или удалённых строк без дополнительного SELECT.
Вставляем строку и сразу получаем созданный ID:
INSERT INTO users (name, email)
VALUES ('Anna Ivanova', 'anna@example.com')
RETURNING id;
Обновляем запись и возвращаем изменённое значение:
UPDATE accounts
SET balance = balance + 500
WHERE id = 10
RETURNING balance AS new_balance;
Удаляем строку и получаем данные до удаления:
DELETE FROM orders
WHERE id = 42
RETURNING order_date, amount;
Возвращаем множество строк:
UPDATE products
SET price = price * 1.10
WHERE category = 'Books'
RETURNING id, price;
🔥 RETURNING упрощает логику: нет необходимости выполнять дополнительный запрос, чтобы получить новые данные — они доступны сразу в рамках одного DML.
➡️ SQL Ready | #практика