SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_c РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
نمایش بیشتر📈 تحلیل کانال تلگرام SQL Ready | Базы Данных
کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 16 616 مشترک است و جایگاه 7 640 را در دسته فناوری و برنامهها و رتبه 39 717 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 16 616 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 01 سپتامبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 1 233 و در ۲۴ ساعت گذشته برابر -2 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 12.49% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 6.17% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 075 بازدید دریافت میکند. در اولین روز معمولاً 1 025 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 23 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند sql, строка, users, индекс, user_id تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_c
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 02 سپتامبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
SEMI JOIN позволяет получить строки, для которых есть совпадение в другой таблице, ANTI JOIN — найти строки без совпадений, а NATURAL JOIN автоматически соединяет таблицы по одноимённым столбцам.
На картинке — наглядное сравнение трёх подходов: SEMI JOIN через EXISTS, ANTI JOIN через NOT EXISTS и NATURAL JOIN, а также показано, чем SEMI JOIN отличается от обычного INNER JOIN.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс• Разбирается архитектура Avalon — масштабируемого Feature Store для централизованного хранения и быстрого получения миллиардов признаков;
• Показывается, как с помощью YDB организованы шардирование, точечные и batch-запросы, импорт данных, ACL и Change Data Capture;
• Рассказывается, какие архитектурные решения позволяют системе работать с 6,5 млрд ключей и выдерживать до 100 тысяч RPS на чтение при P95 около 5 мс.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
• Разбирается механизм поиска корневых блокирующих сессий с помощью системных представлений MS SQL Server;
• Показывается, как реализовать автокиллер на T-SQL с логированием, анализом цепочек блокировок и безопасным удалением зависших транзакций;
• Объясняется, как автоматизировать мониторинг блокировок через SQL Server Agent и сохранить историю для последующего анализа.
🔊 Продолжайте читать на Habr!
➡️ SQL Ready | #статьяAND и OR. Можно использовать row constructor comparison — сравнить сразу кортежи значений.
Например, условие для keyset pagination часто пишут так:
WHERE user_id > :user_id
OR (user_id = :user_id AND id > :id)
Но PostgreSQL умеет выразить то же самое напрямую:
WHERE (user_id, id) > (:user_id, :id)
ORDER BY user_id, id
LIMIT 100;
Сравнение идёт слева направо: сначала user_id, а если значения равны — id. Поэтому конструкция естественно совпадает с лексикографическим порядком составного ORDER BY.
И это не просто сокращение синтаксиса. Под такой запрос можно сделать обычный составной B-tree индекс:
CREATE INDEX orders_user_id_id_idx
ON orders (user_id, id);
Тот же приём работает с диапазонами составных ключей:
WHERE (year, month) >= (2026, 4)
AND (year, month) < (2027, 1)
🔥 Row comparison позволяет заменить громоздкую булеву логику сравнением кортежей и особенно хорошо ложится на keyset pagination и составные B-tree индексы. Важно только помнить про NULL: обычные сравнения с ним могут дать UNKNOWN.
➡️ SQL Ready | #советcommit, branch, merge, fetch, pull и push.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс• Разбираются реальные проблемы, которые DBA чаще всего находят при проверке PostgreSQL в продакшене;
• Показывается, почему бэкапы могут оказаться бесполезными, а широкие права, открытый доступ и отсутствие логов создают серьезные риски;
• Разбираются настройки производительности, долгие транзакции, BLOAT, автовакуум и архитектурные ошибки, которые могут привести к сбоям.
🔊 Продолжайте читать на Habr!
➡️ SQL Ready | #статьяUPDATE и DELETE в PostgreSQL часто используют команды VACUUM и REINDEX. Несмотря на то что обе относятся к обслуживанию базы данных, они решают разные задачи и не являются взаимозаменяемыми.
Создадим таблицу:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email TEXT
);
Добавим данные:
INSERT INTO users (email)
SELECT 'user' || g || '@mail.com'
FROM generate_series(1, 100000) AS g;
Удалим половину строк:
DELETE
FROM users
WHERE id <= 50000;
После выполнения DELETE строки не исчезают из файла таблицы сразу. PostgreSQL использует механизм MVCC, поэтому удалённые версии строк продолжают существовать до тех пор, пока они могут быть нужны активным транзакциям.
Для их обработки используется:
VACUUM users;
VACUUM обрабатывает мёртвые версии строк, освобождая занимаемое ими пространство для повторного использования внутри таблицы. Кроме того, он может очищать соответствующие мёртвые записи в индексах.
При этом обычный VACUUM обычно не уменьшает размер файла таблицы на диске — освободившееся место остаётся внутри таблицы и используется последующими операциями INSERT и UPDATE. Теперь перестроим индекс:
REINDEX INDEX users_pkey;
Или сразу все индексы таблицы:
REINDEX TABLE users;
REINDEX перестраивает индекс на основе актуальных данных таблицы. Эта команда применяется при значительном раздувании индексов, их повреждении, а также в ситуациях, когда анализ показывает, что перестроение может улучшить производительность.
При этом REINDEX не очищает таблицу от мёртвых версий строк и не заменяет выполнение VACUUM. Если же необходимо физически уменьшить размер таблицы и вернуть свободное место операционной системе, используется другая команда:
VACUUM FULL users;
VACUUM FULL полностью переписывает таблицу в новый компактный файл, освобождает место на диске, но требует блокировку уровня ACCESS EXCLUSIVE, поэтому на время выполнения таблица становится недоступной для чтения и записи.
Важно понимать, что в большинстве случаев регулярное обслуживание выполняет autovacuum. Ручной запуск VACUUM, VACUUM FULL или REINDEX обычно является следствием анализа конкретной проблемы, а не стандартной процедурой после большого количества изменений данных.
🔥 Главное отличие: VACUUM обслуживает таблицу и связанные с ней индексы, освобождая пространство, занятое мёртвыми версиями строк, для повторного использования. REINDEX занимается исключительно перестроением индексов. Эти команды решают разные задачи и используются в разных ситуациях.
➡️ SQL Ready | #практикаEXISTS и NOT EXISTS для проверки связей между таблицами.
На картинке — основные типы JOIN в MySQL с примерами SQL-запросов и визуальным объяснением.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурсRETURNING не позволял получить одновременно старое и новое состояние строки. Если нужно было сравнить значения до и после UPDATE, приходилось писать CTE или выполнять дополнительный запрос.
WITH old_data AS (
SELECT id, price
FROM products
WHERE category = 'books'
)
UPDATE products p
SET price = p.price * 1.1
FROM old_data o
WHERE p.id = o.id
RETURNING
o.price AS old_price,
p.price AS new_price;
В PostgreSQL 18 старые и новые значения доступны прямо внутри RETURNING.
UPDATE products
SET price = price * 1.1
WHERE category = 'books'
RETURNING
id,
old.price AS old_price,
new.price AS new_price;
Это особенно удобно для журналирования изменений, аудита, API, которые сразу возвращают результат обновления, и любых сценариев, где нужно сравнить состояние строки до и после изменения.
DELETE FROM products
WHERE discontinued
RETURNING
old.id,
old.name,
old.price;
Та же идея работает и для DELETE: старое состояние строки доступно напрямую через old.
🔥 Небольшое изменение PostgreSQL 18, которое избавляет от лишних CTE и делает RETURNING заметно полезнее.
➡️ SQL Ready | #советhardware: Топовое железо AMD Epyc 9454 / Ryzen 9950x
• net_speed: Аплинки до 10 Гбит/с
• uptime_rate: Честный 99.97%
• privacy_level: 100% анонимность при регистрации
👤 Dev_contacts:
• tech_support: @wuldisupportbot
• root_admin: @Flameochka
👇 Забирайте конфигурацию со скидкой 40% прямо в боте!