SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
نمایش بیشتر📈 تحلیل کانال تلگرام SQL Ready | Базы Данных
کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 17 741 مشترک است و جایگاه 7 336 را در دسته فناوری و برنامهها و رتبه 37 136 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 17 741 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 18 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 696 و در ۲۴ ساعت گذشته برابر 5 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 12.57% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 6.05% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 222 بازدید دریافت میکند. در اولین روز معمولاً 1 069 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 23 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند sql, строка, users, индекс, user_id تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 19 اکتبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
Оставляю ссылочку: Github 📱➡️ SQL Ready | #репозиторий
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 | #совет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 | #совет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 | #практика