SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
显示更多📈 Telegram 频道 SQL Ready | Базы Данных 的分析概览
频道 SQL Ready | Базы Данных (@sql_ready) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 15 552 名订阅者,在 技术与应用 类别中位列第 8 396,并在 俄罗斯 地区排名第 43 154 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 15 552 名订阅者。
根据 11 六月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 56,过去 24 小时变化为 -9,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 12.41%。内容发布后 24 小时内通常能获得 6.30% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 1 931 次浏览,首日通常累积 980 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 24。
- 主题关注点: 内容集中在 sql, строка, user_id, created_at, desc 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_it
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
凭借高频更新(最新数据采集于 12 六月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
ROW_NUMBER() присваивает уникальный порядковый номер строкам внутри логического окна. Данные не объединяются в группы, строки остаются как есть — это ключевое отличие от GROUP BY.
Таблица:
payments(id, user_id, amount, created_at)
Нумеруем платежи каждого пользователя. Окно создаётся по user_id, а нумерация идёт по дате от старых к новым:
SELECT id, user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at ASC) AS rn
FROM payments;
PARTITION BY разбивает данные на сегменты (в данном случае — по пользователю). ORDER BY внутри OVER() задаёт, в каком порядке будут присваиваться номера.
Чтобы найти последний платёж каждого пользователя, меняем порядок сортировки на DESC. Самая свежая запись получит номер 1 в своём окне:
WITH t AS (
SELECT id, user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM payments
)
SELECT * FROM t WHERE rn = 1;
Здесь используем CTE (WITH), чтобы сначала пронумеровать строки, а затем отфильтровать только нужный номер.
Следующий пример — логины пользователей:
auth_logs(id, user_id, ip, login_at)
Ищем первый вход каждого пользователя с каждого IP:
WITH t AS (
SELECT id, user_id, ip,
ROW_NUMBER() OVER (PARTITION BY user_id, ip ORDER BY login_at ASC) AS rn
FROM auth_logs
)
SELECT * FROM t WHERE rn = 1;
🔥 ROW_NUMBER() подходит, когда нужен номер строки в сегменте, важно выбрать первую/последнюю запись по логике сортировки,требуется топ-N по категориям или пользователям.
➡️ SQL Ready | #практика⏺️готовая база на сетевых или локальных дисках ⏺️постоянный primary endpoint ⏺️безопасное подключение через Private Link ⏺️автоматические бэкапы и обслуживания по твоему расписанию🎄🎁 И грант до 10 000 ₽ на запуск — чтобы точно не пришлось вспоминать, как настраивать failover вручную. ➡️Развернуть кластер
• Показан реальный подход к автоматическому развёртыванию PostgreSQL в закрытом контуре;
• Разбирается поддержка нескольких ОС, версий СУБД и схем отказоустойчивости;
• Описана автоматическая проверка соответствия требованиям архитектуры;
• Приведён практический кейс внедрения, рассчитанный на эксплуатацию в крупных корпоративных системах.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
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;
🔥 Это помогает объяснить внезапную деградацию запросов и понять, почему индекс игнорируется.
➡️ SQL Ready | #советOR 1=1 может вернуть все данные из таблицы, а blind SQLi позволяет вытаскивать информацию даже тогда, когда приложение не показывает ошибки и результаты запросов.
На картинке — основные типы SQL-инъекций, которые важно знать при работе с базами данных и backend-логикой.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс• LEFT JOIN — соединяем таблицы, чтобы сохранить всех клиентов, даже тех, у кого нет заказов. • WHERE o,id IS NULL — отбираем только тех, для кого заказов не найдено. • SELECT — выводим имя, email и дату регистрации.➡ SQL Ready | #задача
Loading … ██████████████] 99%Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.
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 — только при полном контроле результата подзапроса.
➡️ SQL Ready | #практика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 и не попадает в ловушки трёхзначной логики.
➡️ SQL Ready | #совет
现已上线!2025 年 Telegram 研究 — 年度关键洞察 
