SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
Ko'proq ko'rsatish📈 Telegram kanali SQL Ready | Базы Данных analitikasi
SQL Ready | Базы Данных (@sql_ready) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 15 552 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 8 396-o'rinni va Rossiya mintaqasida 43 154-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 15 552 obunachiga ega bo‘ldi.
11 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 56 ga, so‘nggi 24 soatda esa -9 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 12.41% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.30% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 931 marta ko‘riladi; birinchi sutkada odatda 980 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 24 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent sql, строка, user_id, created_at, desc kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_it
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 12 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
Оставляю ссылочку: GitHub 📱➡️ SQL Ready | #репозиторий
FOR UPDATE SKIP LOCKED
Строки, которые уже залочены, исключаются из выборки немедленно, без ожидания.
Хотите повторить интерактивно? Откройте 2 SQL-сессии:
Сессия A:
BEGIN;
SELECT id FROM jobs WHERE status='queued' FOR UPDATE;
Сессия B (параллельно):
BEGIN;
SELECT id FROM jobs WHERE status='queued' FOR UPDATE SKIP LOCKED LIMIT 1;
B никогда не вернёт строку, залоченную A, и не будет ждать, вы увидите разные результаты в разных сессиях.
🔥 База данных сама может быть механизмом синхронизации, если выборка делается с SKIP LOCKED. Нет двойной обработки, ожиданий и внешних зависимостей.
➡️ SQL Ready | #советTRANSACTION при автокоммите каждый UPDATE фиксируется отдельно — и есть риск получить несогласованное состояние.
Таблицы:
wallet(user_id, balance)
payments(id, user_id, amount, status)
Сценарий: списать баланс и перевести платёж в done.
Если соединение обрывается между запросами:
UPDATE wallet SET balance = balance - 100 WHERE user_id = 7;
-- сбой соединения тут
UPDATE payments SET status = 'done' WHERE id = 55;
Первое изменение уже сохранено, второе — нет. Итог: деньги списаны, платёж не подтверждён.
Правильный подход — транзакция:
BEGIN;
UPDATE wallet SET balance = balance - 100 WHERE user_id = 7;
UPDATE payments SET status = 'done' WHERE id = 55;
COMMIT;
До COMMIT изменения видны только в текущей сессии и не становятся устойчивыми. Если все шаги успешны — фиксируется сразу всё.
Откат при ошибке:
BEGIN;
UPDATE wallet SET balance = balance - 100 WHERE user_id = 7;
UPDATE payments SET status = 'done' WHERE id = 55;
ROLLBACK;
Пока сессия жива, открытая транзакция не откатывается сама по себе и может удерживать блокировки. Автоматический ROLLBACK происходит именно при разрыве соединения или явном откате.
Нюанс для защиты от гонок и повторной обработки:
UPDATE wallet
SET balance = balance - 100
WHERE user_id = 7 AND balance >= 100;
UPDATE payments
SET status = 'done'
WHERE id = 55 AND status = 'pending';
Оба UPDATE выполняем в одной транзакции, затем проверяем rowcount: если любой запрос затронул 0 строк — ROLLBACK и обработка как ошибка.
🔥 SELECT ... FOR UPDATE также работает только в той же транзакции, где будет обновление. Любая операция списания + фиксации платежа = транзакция.
➡️ SQL Ready | #практикаUPDATE может перезаписывать строку, даже если значение не изменилось.
IS DISTINCT FROM сравнивает значения NULL-безопасно и без UNKNOWN:
AND u.name IS DISTINCT FROM 'Alice';
Если name уже Alice — условие ложно, и строка не обновляется вообще.
Это правило можно применить к любым колонкам:
AND u.email IS DISTINCT FROM EXCLUDED.email;
Паттерн остаётся тем же: обновление только при расхождении.
Проверьте сами на тесте:
CREATE TABLE users(id int PRIMARY KEY, name text);
INSERT INTO users VALUES (1, 'Bob');
Запустите 2 раза UPDATE сверху, второй раз таблица не изменится и ничего не запишет.
🔥 UPDATE должен менять только то, что отличается и SQL уже даёт для этого инструменты.
➡️ SQL Ready | #советproducts(id, category, price)
Нужно выбрать самый дорогой товар в каждой категории, но при этом видеть все колонки строки:
SELECT *
FROM (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC, id DESC) AS rn
FROM products
) t
WHERE rn = 1;
PARTITION BY формирует независимые окна для каждой категории.
ROW_NUMBER() нумерует строки внутри каждой партиции, а не по всей таблице.
Если нужны не только первые, а, например, топ-3 в каждой категории:
SELECT id, category, price
FROM (
SELECT
id, category, price,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC, id DESC) AS rn
FROM products
) t
WHERE rn <= 3
ORDER BY category, price DESC;
Тут важно: без PARTITION BY запрос взял бы топ-3 по всей таблице, а не по категориям.
Оконные функции не требуют GROUP BY, потому что не агрегируют (не схлопывают) строки, а дополняют их аналитическими метками.
Ещё полезный трюк — находить максимум в группе без GROUP BY и JOIN, через коррелированный подзапрос:
SELECT *
FROM products
WHERE price = (
SELECT MAX(price)
FROM products p2
WHERE p2.category = products.category
);
Этот запрос не агрегирует основную таблицу и вернёт несколько строк, если в категории есть товары с одинаковой максимальной ценой (ties).
🔥 Используйте PARTITION BY в оконных функциях, когда логика должна применяться внутри каждой группы независимо, а строки нужно сохранить целиком.
➡️ SQL Ready | #практикаWHERE user_id NOT IN (SELECT id FROM users);
Если подзапрос вернёт хотя бы один NULL, условие станет UNKNOWN, и не вернётся ни одной строки.
Правильнее и безопаснее паттерн NOT EXISTS:
WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id);
Он корректно работает при NULL, не ломает логику и читается однозначно.
Хотите повторить? Проверьте разницу сами:
CREATE TABLE users(id int);
INSERT INTO users VALUES (1), (2), (NULL);
Теперь запустите:
SELECT 1 AS test WHERE 3 NOT IN (SELECT id FROM users);
Результат будет пустым.
🔥 А если переписать через NOT EXISTS, логика вернётся в норму.
➡️ SQL Ready | #советВ этой шпаргалке собраны ключевые функции и операторы PostgreSQL для создания, трансформации, агрегации и фильтрации массивов, а также проверки их пересечения и вхождения элементов. Материал охватывает приведение типов, разворачивание массивов в строки, сбор данных в массивы и использование операторов для логических проверок.
➡️ SQL Ready | #шпораVALUES как виртуальную таблицу, поэтому можно писать много строк прямо в INSERT:
INSERT INTO users (id, email, name) VALUES
(1, 'alice@mail.com', 'Alice'),
(2, 'bob@mail.com', 'Bob'),
(3, 'carol@mail.com', 'Carol');
Это работает мгновенно, просто читается и не создаёт лишних объектов в базе.
Хотите протестировать в своем проекте? Создайте таблицу и вставьте строки выше:
CREATE TABLE users (
id int PRIMARY KEY,
email text,
name text
);
🔥 Пригодится, когда нужно быстро заполнить таблицу для проверки логики.
➡️ SQL Ready | #советLoading … ██████████████] 99%Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.
Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
