Базы данных (Data Base)

🚀 Подборка полезных 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 лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоур

🔥 Шпаргалка по SQL с основными командами и примерами 1. Основные команды SQL SELECT 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) SELECT city, COUNT(*) FROM users GROUP BY city; -- Количество пользователей в каждом городе SELECT city, AVG(age) FROM users GROUP BY city HAVING AVG(age) > 25; -- Средний возраст > 25 SELECT MAX(salary) FROM employees; -- Максимальная зарплата SELECT SUM(sales) FROM orders WHERE date >= '2024-01-01'; -- Сумма продаж с 2024 года 4. Сортировка (ORDER BY) SELECT * FROM users ORDER BY age ASC; -- Сортировка по возрасту (по возрастанию) SELECT * FROM users ORDER BY age DESC; -- Сортировка по убыванию 5. Соединение таблиц (JOIN) SELECT users.name, orders.amount FROM users JOIN orders ON users.id = orders.user_id; -- Внутреннее соединение SELECT users.name, orders.amount FROM users LEFT JOIN orders ON users.id = orders.user_id; -- Левый JOIN (все из users) SELECT users.name, orders.amount FROM users RIGHT JOIN orders ON users.id = orders.user_id; -- Правый JOIN (все из orders) 6. Создание и изменение таблиц (CREATE, ALTER, DROP) CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(100), age INT ); -- Создание

🔥 Оптимизация запросов: Как убрать тормоза в SQL? Сейчас покажу вам, как ускорить медленный SQL-запрос, который выполняется слишком долго. Если у вас в проекте есть запросы, которые выполняются секундами, а не миллисекундами, пора что-то менять! 🚀 Разбор примера Допустим, у нас есть такой запрос: SELECT * FROM orders WHERE customer_id = 123 ORDER BY order_date DESC; Кажется простым, но выполняется медленно. В чём может быть проблема? 📌 Основные причины тормозов: 1️⃣ Нет нужного индекса – если customer_id или order_date не индексированы, база будет делать полный скан таблицы. 2️⃣ Слишком много данных – если таблица огромная, ORDER BY без индекса будет работать медленно. 3️⃣ Использование SELECT * – загружает ненужные колонки и увеличивает нагрузку. ✅ Как ускорить? ✔ Добавляем индекс (если его нет): CREATE INDEX idx_orders_customer ON orders(customer_id, order_date DESC); ✔ Выбираем только нужные колонки: SELECT order_id, order_date FROM orders WHERE customer_id = 123 ORDER BY order_date DESC; ✔ Лимитируем выборку (если нужен только последний заказ): SELECT order_id, order_date FROM orders WHERE customer_id = 123 ORDER BY order_date DESC LIMIT 1; Добавление индекса + правильный выбор колонок + LIMIT = в разы быстрее! 🚀 📲 Мы в MAX #db 👉 @database_info

🔥 Оптимизация индексов: частая ошибка 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); CREATE INDEX idx_order_date ON orders(order_date); CREATE INDEX idx_customer_order_date ON orders(customer_id, order_date); На первый взгляд, всё логично, но есть проблема: индекс idx_customer_order_date покрывает оба предыдущих индекса! 💡Как исправить? Можно удалить idx_customer и idx_order_date, так как составной индекс (idx_customer_order_date) способен выполнять их работу. 📌 Как проверить ненужные индексы? 1️⃣ В PostgreSQL: SELECT indexrelid::regclass, pg_size_pretty(pg_relation_size(indexrelid)) FROM pg_stat_user_indexes ORDER BY pg_relation_size(indexrelid) DESC; 2️⃣ В MySQL: SHOW INDEX FROM orders; Здесь ищем индексы, которые дублируют друг друга. Вывод: Чем меньше избыточных индексов — тем быстрее работает ваша база данных. Проверьте свои индексы прямо сейчас! 📲 Мы в MAX #db 👉 @database_info

📊 Зачем 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 - вот оно. Индекс-то используется, но данные не в кэше, приходится читать с диска. А диск медленный. Решение? Подумать о горячем кэше, пачке RAM или REINDEX, если индекс раздулся. Каждый EXPLAIN - как рентген. Не читаешь - лечишь наугад. 📲 Мы в MAX #db 👉 @database_info

Сегодня расскажу вам про одну часто недооценённую, но крайне полезную 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? Он буквально говорит: «Для каждой строки из Orders выполни подзапрос с её параметрами». Это похоже на foreach, где внутренняя выборка может меняться в зависимости от строки внешней таблицы. Аналог в PostgreSQL: SELECT o.order_id, p.product_name, p.amount FROM orders o, LATERAL ( SELECT * FROM products p WHERE p.order_id = o.order_id ORDER BY p.amount DESC LIMIT 1 ) p; 🔥 Используйте CROSS APPLY, когда: - Нужна подстрочная логика внутри запроса - Не получается реализовать через обычный JOIN - Вы работаете с функциями, которые возвращают таблицу (TVF) 📲 Мы в MAX #db 👉 @database_info

🧩 Сегодня покажу вам простой, но крайне полезный приём, как находить “тяжёлые” запросы в 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 ORDER BY total_time DESC LIMIT 10; 🔍 Тут видно, какие запросы в сумме "съели" больше всего времени. И это гораздо честнее, чем смотреть только на mean_time или calls по отдельности. 💡Совет: подключите pg_stat_statements на проде и делайте такой анализ хотя бы раз в неделю. Это поможет находить проблемные места в приложении до того, как начнётся пожар. 📲 Мы в MAX #db 👉 @database_info

🧩 Как сделать 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 — формат архива и сжатие - -P — прогресс в консоли Важно: Пользователь repl_user должен быть прописан в pg_hba.conf и иметь роль REPLICATION. А если добавить в cron, то получишь стабильный ночной бэкап без боли. 📲 Мы в MAX #db 👉 @database_info

🚀 Сегодня покажу, как быстро диагностировать «тормоза» в 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 → Сразу ясно: кто-то держит блокировку на таблицу, и все остальные ждут. 🔥Чтобы найти виновника, можно запустить: SELECT blocked_locks.pid AS blocked_pid, blocking_locks.pid AS blocking_pid, blocked_activity.query AS blocked_query, blocking_activity.query AS blocking_query FROM pg_locks blocked_locks JOIN pg_locks blocking_locks ON blocked_locks.locktype = blocking_locks.locktype AND blocked_locks.database IS NOT DISTINCT FROM blocking_locks.database AND blocked_locks.relation IS NOT DISTINCT FROM blocking_locks.relation AND blocked_locks.page IS NOT DISTINCT FROM blocking_locks.page AND blocked_locks.tuple IS NOT DISTINCT FROM blocking_locks.tuple AND blocked_locks.transactionid IS NOT DISTINCT FROM blocking_locks.transactionid AND blocked_locks.classid IS NOT DISTINCT FROM blocking_locks.classid AND blocked_locks.objid IS NOT DISTINCT FROM blocking_locks.objid AND blocked_locks.objsubid IS NOT DISTINCT FROM blocking_locks.objsubid AND blocked_locks.pid != blocking_locks.pid JOIN pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid JOIN pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid WHERE NOT blocked_locks.granted; Этот запрос покажет, кто кого блокирует, и с каким з

Как быстро найти “тяжёлые” запросы в 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 FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5; А если интересует то, что прямо сейчас выполняется — тогда так: SELECT pid, now() - query_start AS duration, state, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC; Я часто сохраняю эти запросы в отдельный .sql-файл, чтобы запускать сразу при проблемах с производительностью. Полезно добавить в .psqlrc алиас или даже обернуть в скрипт. Как вы ищете “тяжёлые” запросы в проде? Поделитесь в комментариях. 📲 Мы в MAX #db 👉 @database_info