Latest posts
Базы данных (Data Base)
22 Sept, 04:48
⚡️ Совет по работе с базами данных 💡Уникальные индексы с исключением определенных строкСоздание уникальных индексов в некоторых случаях невозможно из-за дублирования значений - например, в строках, помеченных как «мягко удаленные» (soft-deleted). Исключив такие строки из индекса, можно корректно настроить ограничение уникальности. В MySQL частичные уникальные индексы (unique partial indexes) требуют эмуляции.В современных базах данных часто используется паттерн Soft Delete, когда данные не удаляются физически, а помечаются флагом is_deleted = true.Если вы хотите, чтобы поле email было уникальным только для активных пользователей, обычный уникальный индекс выдаст ошибку при попытке регистрации нового пользователя с почтой, которая уже есть в «корзине». Использование частичного индекса решает эту проблему, позволяя игнорировать помеченные на удаление записи.Нюанс для MySQL: В от
Базы данных (Data Base)
21 Sept, 07:42
Как быстро найти “тяжёлые” запросы в PostgreSQLСегодня покажу простой способ найти самые ресурсоёмкие запросы, которые прямо сейчас выполняются в PostgreSQL. Это помогает, когда база начинает “тормозить”, а понять почему - сложно.Используем pg_stat_activity и pg_stat_statements. Но сначала убедись, что pg_stat_statements включён:-- Проверка: SELECT FROM pg_extension WHERE extname = 'pg_stat_statements';-- Включение (если не установлен): CREATE EXTENSION pg_stat_statements;Теперь сам запрос на поиск “тяжёлых” запросов:SELECT query, calls, total_exec_time, mean_exec_time, rowsБазы данных (Data Base)
20 Sept, 08:55
🚀 Сегодня покажу, как быстро диагностировать «тормоза» в PostgreSQL - без всяких внешних тулов и дополнительных логов. Только pg_stat_activity и немного здравого смысла.Пользователи жалуются - "всё тормозит". Как понять, что именно? Открываем сессию в psql от суперпользователя и запускаем:SELECT pid, state, wait_event_type, wait_event, query, now() - query_start AS duration FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC;📌 Что это нам даёт: - Видим все активные (и зависшие) запросы. - Сколько времени они уже выполняются (duration). - На чём конкретно «висят»: CPU, IO, Lock, Client и т.д. (wait_event_type + wait_event).Пример:wait_event_type: Lock wait_event: relation→ Сразу ясно: кто-то держит блокировку на таблицу, и все остальные ждут.Базы данных (Data Base)
18 Sept, 05:33
🧩 Как сделать backup PostgreSQL с минимальной нагрузкой на прод?Сегодня покажу один из самых эффективных способов бэкапа PostgreSQL — с помощью pg_basebackup + реплики.Сценарий: у нас есть продовый PostgreSQL и настроенная горячая реплика (streaming replication). Зачем использовать реплику для бэкапа?Причины: - 💡 На проде бэкап может замедлить отклик приложения. - 🔁 Реплика — отличный способ разгрузить основной сервер. - ⏱ Бэкап с pg_basebackup возможен только на стопнутой БД или через репликацию.Как сделать:pg_basebackup -h replica.host -U repl_user -D /backup/pg -F tar -z -PПояснения: - -h — адрес реплики - -U — пользователь с правами репликации - -D — куда класть бэкап - -F tar -z — формат архива и сжатиеБазы данных (Data Base)
17 Sept, 09:15
🎯 Сегодня покажу простой способ ускорить запросы в PostgreSQL, даже не трогая сам SQL-код.Часто вижу, как разработчики и админы оптимизируют запросы, играя с индексами или переписывая JOIN'ы. Но забывают про один мощный инструмент — ANALYZE.ANALYZE обновляет статистику по таблицам. Эта статистика — хлеб для планировщика запросов. Если она устарела, PostgreSQL может выбрать неэффективный план, даже если у вас всё индексировано как надо.👨🔧 Простой пример:ANALYZE my_big_table;Запускаешь — и вдруг сложный JOIN срабатывает в разы быстрее. Потому что PostgreSQL теперь знает, какие там объемы данных, сколько уникальных значений в колонках и т.п.🧠 Совет: если ты регулярно заливаешь данные в таблицы (например, через ETL или бэкапы) — добавь ANALYZE в конец процедуры. Это дёшево, но может дать мощный прирост производительности.Можно даже так:VACUUM ANALYZE my_big_table;ТакБазы данных (Data Base)
17 Sept, 07:02
Этот файл был удален пользователемВстречаемся в Москве с теми, кто отвечает за хранение данных бизнеса. Обсудим, как решить задачу со звездочкой — уберечь массивы файлов и резервных копий от атак шифровальщиков, утечки или случайной перезаписи.На бизнес-ужине эксперты провайдера ИТ-инфраструктуры Selectel расскажут: ➕как устроено хранилище S3 под капотом; ➕какие угрозы данным существуют и как выстроить многослойную систему защиты; ➕почему защита данных — это не статья расходов, а управление рисками.Будет актуально руководителям в ИТ-компаниях, старшим архитекторам, системным администраторам. Поговорим и про стратегию хранения, и про реализацию.📆 24 сентября (чт), 18:30 📍Москва, м. Динамо
Базы данных (Data Base)
14 Sept, 08:44
🧩 Сегодня покажу вам простой, но крайне полезный приём, как находить “тяжёлые” запросы в PostgreSQL, которые тормозят базу.📌 Если у вас база под нагрузкой, и “что-то всё стало медленно”, первым делом проверьте:SELECT pid, now() - query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 5;Этот запрос показывает топ-5 самых долгих активных запросов. Обратите внимание на query_start - именно он поможет понять, кто завис и тормозит остальных.А если хотите посмотреть историю медленных запросов за последние часы/дни - подключайте pg_stat_statements:SELECT calls, total_time, mean_time, query FROM pg_stat_statementsБазы данных (Data Base)
13 Sept, 06:27
Сегодня расскажу вам про одну часто недооценённую, но крайне полезную SQL-фишку — CROSS APPLY в SQL Server (и его аналог в других СУБД — LATERAL).Когда обычный JOIN бессиленДопустим, у нас есть таблица Orders, и мы хотим для каждой строки выбрать топ-1 продукт по сумме, но выборка зависит от строки — тут уже обычный JOIN не справится. Вот пример, где приходит на помощь CROSS APPLY:SELECT o.OrderID, p.ProductName, p.Amount FROM Orders o CROSS APPLY ( SELECT TOP 1 FROM Products p WHERE p.OrderID = o.OrderID ORDER BY p.Amount DESC ) p;Что делает CROSS APPLY?Базы данных (Data Base)
10 Sept, 06:52
📊 Зачем DBA нужно уметь читать планы выполнения запросов (EXPLAIN)?Почему навык чтения плана выполнения запроса - это не просто галочка в резюме, а реальный способ спасать прод от тормозов и неожиданных фулл-сканов.Когда приходит запрос от разработчика: "Почему тормозит?" - ты открываешь EXPLAIN (ANALYZE, BUFFERS) и видишь:Seq Scan on users (cost=0.00..44231.00 rows=1000000 width=64) Filter: (status = 'active')И тут всё понятно: фильтрация идёт по колонке без индекса, Postgres делает полный проход по таблице. Один CREATE INDEX - и запрос летит 🚀Но не всё так просто. Иногда план говорит:Index Scan using idx_users_status on users Index Cond: (status = 'active')А запрос всё равно медленный. Почему?➡️ Buffers: shared hit=5 read=100000 dirtied=0 - вот оно. Индекс-то используется, но данные не в кэше, приходится читать с диска. А диск медленный. Решение? Подумать о горячемБазы данных (Data Base)
8 Sept, 05:44
💡7 обязательных стратегий для масштабирования вашей базы данных.1 - Индексация: Проверьте шаблоны запросов вашего приложения и создайте подходящие индексы.2 - Материализованные представления: Предварительно вычислите результаты сложных запросов и сохраните их для быстрого доступа.3 - Денормализация: Уменьшите количество сложных соединений (join), чтобы улучшить производительность запросов.4 - Вертикальное масштабирование: Увеличьте мощность вашего сервера базы данных, добавив больше ЦП, оперативной памяти или хранилища.5 - Кэширование: Сохраните часто запрашиваемые данные в более быстром слое хранения, чтобы снизить нагрузку на базу данных.6 - Репликация: Создайте реплики вашей основной базы данных на разных серверах для масштабирования чтений.
Базы данных (Data Base)
3 Sept, 06:19
SQL JOINs наглядно: как работать с объединением таблицХотите лучше понимать SQL JOIN? Вот наглядная шпаргалка с примерами и визуализацией!🔹 INNER JOIN – пересечение двух таблиц, возвращает только совпадающие строки.SELECT FROM A INNER JOIN B ON A.key = B.key;🔹 FULL JOIN – объединяет все данные из обеих таблиц, заполняя пропущенные значения NULL.SELECT FROM A FULL JOIN B ON A.key = B.key;🔹 FULL JOIN с фильтрацией NULL – выбирает только строки, которые есть только в одной из таблиц.SELECT FROM A
Базы данных (Data Base)
1 Sept, 06:47
Визуализация SQL-запросовМентальная модель, помогающая представить, как выполняются SQL-запросы.Фактическая последовательность выполнения может отличаться от этой модели из-за стратегий оптимизации, применяемых оптимизатором запросов.📲 Мы в MAX#db👉 @database_info
Базы данных (Data Base)
31 Aug, 05:14
🔥 Оптимизация индексов: частая ошибка DBA 🔥Сегодня разберём распространённую ошибку, которую совершают многие администраторы баз данных — избыточные индексы.💡Проблема Добавление индексов — это полезно, но если их становится слишком много, то база данных начинает тормозить при вставке, обновлении и удалении данных. Почему? Потому что каждый индекс требует дополнительного обслуживания при изменениях в таблице.💡Пример ошибки Представим таблицу orders:CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT NOT NULL, order_date DATE NOT NULL, total DECIMAL(10,2) NOT NULL );Допустим, мы добавляем индексы:CREATE INDEX idx_customer ON orders(customer_id);Базы данных (Data Base)
28 Aug, 05:38
🔥 Оптимизация запросов: Как убрать тормоза в SQL?Сейчас покажу вам, как ускорить медленный SQL-запрос, который выполняется слишком долго. Если у вас в проекте есть запросы, которые выполняются секундами, а не миллисекундами, пора что-то менять!🚀 Разбор примера Допустим, у нас есть такой запрос:SELECT FROM orders WHERE customer_id = 123 ORDER BY order_date DESC;Кажется простым, но выполняется медленно. В чём может быть проблема?📌 Основные причины тормозов: 1️⃣ Нет нужного индекса – если customer_id или order_date не индексированы, база будет делать полный скан таблицы. 2️⃣ Слишком много данных – если таблица огромная, ORDER BY без индекса будет работать медленно. 3️⃣ Использование SELECT – загружает ненужные колонки и увеличивает нагрузку.✅ Как ускорить?Базы данных (Data Base)
27 Aug, 19:19
🔥 Шпаргалка по SQL с основными командами и примерами1. Основные команды SQLSELECT column1, column2 FROM table_name; -- Выборка данных SELECT FROM table_name; -- Выборка всех данных INSERT INTO table_name (column1, column2) VALUES ('value1', 'value2'); -- Добавление данных UPDATE table_name SET column1 = 'value' WHERE condition; -- Обновление данных DELETE FROM table_name WHERE condition; -- Удаление данных2. Фильтрация данных (WHERE, AND, OR, LIKE, IN, BETWEEN)SELECT FROM users WHERE age > 18; -- Возраст больше 18 SELECT FROM users WHERE city = 'Москва' AND age > 18; -- Два условия SELECT FROM users WHERE name LIKE 'A%'; -- Начинается с 'A' SELECT FROM users WHERE age BETWEEN 18 AND 30; -- Возраст от 18 до 30 SELECT FROM users WHERE city IN ('Москва', 'Санкт-Петербург'); -- Город Москва или Питер3. Группировка и агрегатные функции (GROUP BY, HAVING, COUNT, SUM, AVG, MAX, MIN)Базы данных (Data Base)
24 Aug, 06:39
🔥 Оптимизация SQL-запросов: 5 ключевых техникСегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀1️⃣ Используйте индексы Индексы – это ускоритель запросов. Если у вас часто выполняются WHERE, JOIN или ORDER BY по определенному столбцу – создайте для него индекс. Но не переборщите: индексы ускоряют чтение, но замедляют вставку и обновление данных.2️⃣ Избегайте SELECT Выбирайте только нужные столбцы. SELECT может загружать ненужные данные и нагружать сервер. Лучше указывать конкретные столбцы.3️⃣ Нормализация или денормализация? Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию!4️⃣ Кеширование запросов Если запрос выполняется часто и данные редко меняются, используйте QUERY CACHE или
Базы данных (Data Base)
23 Aug, 11:06
🚀 Подборка полезных IT каналов в MaxСистемное администрирование, DevOps 📌https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. https://max.ru/tipsysdmin Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса)Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхакMAXСистемный Администратор | Sysadmin Windows & Linux Server. …Купить рекламу: https://telega.in/m/i_odmin Блог практикующего админа. Настройка Windows Server, Active Directory (AD), GPO и терминальных серверов (RDP). Раб…Базы данных (Data Base)
20 Aug, 06:24
Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся!🔹 Миф: индексы всегда ускоряют запросы На самом деле, индекс может даже замедлить выполнение, если: ✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы. ✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице. ✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE.🔹 Как правильно анализировать? Используйте EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания: 🔍 Используется ли индекс? 🔍 Сколько строк проходит сканирование? 🔍 Есть ли операции сортировки, которые можно
Базы данных (Data Base)
19 Aug, 06:57
🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения?🛠 Основные проблемы: 🔹 Чрезмерное количество JOIN – могут приводить к тяжелым вычислениям. 🔹 Неправильные индексы – или их отсутствие вообще. 🔹 Подзапросы вместо JOIN – иногда работают хуже, чем соединения. 🔹 Ненужные SELECT – выбираем только нужные колонки. 🔹 Фильтрация после JOIN – фильтруем данные как можно раньше.✅ Как ускорить запрос? 1️⃣ Проверьте индексы – используйте EXPLAIN перед выполнением запроса. Если сканируется весь таблица (Full Table Scan), значит, нужны индексы. 2️⃣ Разбейте сложный запрос на части – иногда лучше записать результат во временную таблицу. 3️⃣ Избегайте SELECT – указывайте только нужные колонки. 4️⃣ Используйте EXISTS вместо IN – в подзапросах это часто работает быстрее. 5️⃣ Тестируйте с разными JOIN – попробуйте INNER JOIN, LEFT JOIN, а в некоторых случаях UNION. 6️⃣ Оптимизируй
Базы данных (Data Base)
18 Aug, 20:45
Шпаргалка по оконным функциям в SQL📲 Мы в MAX#db👉 @database_info
Related Channels
Other channels in the same section of the catalogue.
