Базы данных (Data Base)
رفتن به کانال در Telegram
Базы данных (Data Base). По всем вопросам @evgenycarter
نمایش بیشتر
شبکه:8 031
مشترکین
-224 ساعت
-17 روز
-2330 روز
در حال بارگذاری داده‌ها
کانال‌های مشابه
ابر برچسب‌ها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+60
در 0 کانال‌ها
سپتامبر '26
+61
در 0 کانال‌ها
Get PRO
اوت '26
+57
در 0 کانال‌ها
Get PRO
ژوئیه '26
+61
در 0 کانال‌ها
Get PRO
ژوئن '26
+49
در 0 کانال‌ها
Get PRO
مه '26
+81
در 0 کانال‌ها
Get PRO
آوریل '26
+56
در 0 کانال‌ها
Get PRO
مارس '26
+85
در 0 کانال‌ها
Get PRO
فوریه '26
+92
در 0 کانال‌ها
Get PRO
ژانویه '26
+82
در 0 کانال‌ها
Get PRO
دسامبر '25
+87
در 0 کانال‌ها
Get PRO
نوامبر '25
+137
در 31 کانال‌ها
Get PRO
اکتبر '25
+101
در 1 کانال‌ها
Get PRO
سپتامبر '25
+178
در 36 کانال‌ها
Get PRO
اوت '25
+159
در 1 کانال‌ها
Get PRO
ژوئیه '25
+197
در 27 کانال‌ها
Get PRO
ژوئن '25
+215
در 19 کانال‌ها
Get PRO
مه '25
+201
در 44 کانال‌ها
Get PRO
آوریل '25
+227
در 40 کانال‌ها
Get PRO
مارس '25
+202
در 38 کانال‌ها
Get PRO
فوریه '25
+176
در 31 کانال‌ها
Get PRO
ژانویه '25
+230
در 33 کانال‌ها
Get PRO
دسامبر '24
+183
در 34 کانال‌ها
Get PRO
نوامبر '24
+188
در 32 کانال‌ها
Get PRO
اکتبر '24
+192
در 29 کانال‌ها
Get PRO
سپتامبر '24
+250
در 28 کانال‌ها
Get PRO
اوت '24
+137
در 17 کانال‌ها
Get PRO
ژوئیه '24
+139
در 0 کانال‌ها
Get PRO
ژوئن '24
+176
در 23 کانال‌ها
Get PRO
مه '24
+169
در 19 کانال‌ها
Get PRO
آوریل '24
+161
در 0 کانال‌ها
Get PRO
مارس '24
+202
در 20 کانال‌ها
Get PRO
فوریه '24
+178
در 18 کانال‌ها
Get PRO
ژانویه '24
+289
در 23 کانال‌ها
Get PRO
دسامبر '23
+246
در 25 کانال‌ها
Get PRO
نوامبر '23
+246
در 17 کانال‌ها
Get PRO
اکتبر '23
+266
در 18 کانال‌ها
Get PRO
سپتامبر '23
+247
در 0 کانال‌ها
Get PRO
اوت '23
+192
در 0 کانال‌ها
Get PRO
ژوئیه '23
+185
در 0 کانال‌ها
Get PRO
ژوئن '23
+223
در 0 کانال‌ها
Get PRO
مه '23
+217
در 0 کانال‌ها
Get PRO
آوریل '23
+309
در 0 کانال‌ها
Get PRO
مارس '23
+282
در 0 کانال‌ها
Get PRO
فوریه '23
+168
در 0 کانال‌ها
Get PRO
ژانویه '23
+175
در 0 کانال‌ها
Get PRO
دسامبر '22
+224
در 0 کانال‌ها
Get PRO
نوامبر '22
+174
در 0 کانال‌ها
Get PRO
اکتبر '22
+321
در 0 کانال‌ها
Get PRO
سپتامبر '22
+380
در 0 کانال‌ها
Get PRO
اوت '22
+295
در 0 کانال‌ها
Get PRO
ژوئیه '22
+538
در 0 کانال‌ها
Get PRO
ژوئن '22
+569
در 0 کانال‌ها
Get PRO
مه '22
+891
در 0 کانال‌ها
Get PRO
آوریل '22
+3 160
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 26 اکتبر | +6 | |||
| 25 اکتبر | +1 | |||
| 24 اکتبر | 0 | |||
| 23 اکتبر | +2 | |||
| 22 اکتبر | +4 | |||
| 21 اکتبر | 0 | |||
| 20 اکتبر | +5 | |||
| 19 اکتبر | +3 | |||
| 18 اکتبر | 0 | |||
| 17 اکتبر | +1 | |||
| 16 اکتبر | +2 | |||
| 15 اکتبر | +1 | |||
| 14 اکتبر | +3 | |||
| 13 اکتبر | +2 | |||
| 12 اکتبر | +5 | |||
| 11 اکتبر | +5 | |||
| 10 اکتبر | +1 | |||
| 09 اکتبر | +1 | |||
| 08 اکتبر | +3 | |||
| 07 اکتبر | 0 | |||
| 06 اکتبر | 0 | |||
| 05 اکتبر | +4 | |||
| 04 اکتبر | +5 | |||
| 03 اکتبر | +2 | |||
| 02 اکتبر | +2 | |||
| 01 اکتبر | +2 |
پست‌های کانال
PostgreSQL или MySQL?
Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇
🔷 PostgreSQL:
🔵Поддержка JSONB с индексами - почти как NoSQL внутри SQL
🔵CTE, оконные функции, полнотекстовый поиск - топ для аналитики
🔵Расширяемость: можно писать свои типы, функции, операторы
🔵Хорош для сложных запросов, аналитики, геоданных (PostGIS)
🔻 Минусы:
– Сложнее в настройке и оптимизации
– Меньше хостингов out-of-the-box (но всё быстро меняется)
🔶 MySQL (особенно InnoDB / MariaDB):
🔵Быстрее на простых SELECT/INSERT, если запросы примитивные
🔵Больше ready-to-go хостингов и тулов для web
🔵Низкий порог входа - быстрее поднимается новичками
🔻 Минусы:
– Слабее в сложных SQL-конструкциях
– Нет нормальной поддержки CTE до недавнего времени
– JSON без индексации (в MySQL < 8.0)
Вывод:
🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами, MySQL зайдёт.
📊 Если строишь data-heavy приложения, BI, ETL или гео-системы, PostgreSQL без шансов.
📲 Мы в MAX
#db
👉 @database_info
| 2 |  💣 NULL — тихий саботаж в твоей БД
На первый взгляд, NULL — просто отсутствие значения. Но на практике это частый источник багов, неверных аналитик и проблем в бизнес-логике.
📉 Антипаттерн: беспечное обращение с NULL
Примеры:
SELECT * FROM users WHERE age > 18; -- Пользователи с age = NULL не попадут
Ты думаешь, что отбираешь всех взрослых, но age = NULL тут "выпадает", ведь NULL > 18 → UNKNOWN.
WHERE col1 = col2 -- Не сработает, если хотя бы одно значение NULL
🙈 Проблема: NULL не равно даже самому себе (NULL != NULL).
📉 Итоги: ошибки в JOIN'ах, WHERE-фильтрах, расчетах.
🛡 Как защититься:
✅ Явно учитывай NULL:
WHERE age > 18 OR age IS NULL -- если хочешь включить "неизвестный возраст"
✅ Используй COALESCE:
SELECT COALESCE(discount, 0) FROM orders -- подставим 0, если скидка не указана
✅ Проверяй NULL через IS NULL / IS NOT NULL
✅ Для агрегаций учитывай поведение NULL:
AVG(column) -- пропустит NULL'ы, но COUNT(column) тоже не посчитает их!
Вывод:
NULL — не "ничего", а "неизвестно".
Пиши запросы так, как будто NULL всегда где-то прячется — и он не на твоей стороне.
Сохрани, чтобы не ловить грабли 💥
📲 Мы в MAX
#db
👉 @database_info | 433 |
| 3 | ⚡️ Индексы в базах данных: как заставить запросы летать
Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.
Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.
✅ Зачем нужны:
* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).
❌ Чем платим (минусы):
* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.
🛠 Чек-лист: индексировать или нет?
🟢 Обязательно индексируем:
1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).
🔴 НЕ индексируем:
1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.
💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.
📲 Мы в MAX
#db
👉 @database_info | 715 |
| 4 |  🧱 Антипаттерн: Ненормализованная схема в SQL
Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче.
Пример:
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_email TEXT,
product_1_name TEXT,
product_1_price NUMERIC,
product_2_name TEXT,
product_2_price NUMERIC
);
😰 Что пойдет не так:
– Дублирование данных — имя клиента повторяется в каждом заказе.
– Нет масштабируемости — максимум 2 продукта? А если будет 3?
– Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи.
– Адские апдейты — изменить email клиента надо во всех заказах.
✅ Как правильно:
1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items.
2. Используй внешние ключи.
3. Не бойся JOIN'ов — они для этого и придуманы.
Пример нормализованной структуры:
-- Таблица клиентов
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name TEXT,
email TEXT
);
-- Таблица заказов
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id)
);
-- Таблица товаров
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name TEXT,
price NUMERIC
);
-- Связка товаров и заказов
CREATE TABLE order_items (
order_id INT REFERENCES orders(id),
product_id INT REFERENCES products(id),
quantity INT
);
📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.
Сохрани, чтобы не забыть — и не повторять чужих ошибок.
📲 Мы в MAX
#db
👉 @database_info | 826 |
| 5 |  🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД
Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё.
Спойлер: потом будет больно.
Вот как этого избежать 👇
1. Начинай с нормализации
– Смотри, какие поля повторяются.
– Разделяй по сущностям: клиент ≠ заказ ≠ товар.
– Нормальные формы — не академикам, а тебе на пользу.
2. Определи связи заранее
– Один ко многим? Многие ко многим?
– Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала.
3. Не бойся JOIN-ов
– Да, их становится больше.
– Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.
4. Планируй под рост
– Временные костыли становятся постоянными.
– Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.
5. Назначь ID-шки как бог велел
– PRIMARY KEY + автоинкремент или UUID.
– Не делай email или name ключом — это путь в баги.
🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её.
А переделывать схему сложнее, чем сделать нормально с самого начала.
📲 Мы в MAX
#db
👉 @database_info | 815 |
| 6 | 🚀 Подборка полезных 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 Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼💻👩💻
Шутки программистов 📌
https://max.ru/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free
Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров
Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике
Вакансии в IT📌
https://max.ru/progjob
https://max.ru/channel_rabotait
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Городские📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
https://max.ru/channel_krasnodar_novosty Краснодар Новости
https://max.ru/channel_novosibirsk_novosti Новосибирск
https://max.ru/channel_samara_novosti Новости Самары
https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга
https://max.ru/channel_kazan_novosti Новости Казани
https://max.ru/channel_omsk_novosti Новости Омска
https://max.ru/channel_moskva_24 Москва 24 | 693 |
| 7 |  Без каких навыков не обойтись в ИТ прямо сейчас?
Разбираемся с одной из самых популярных СУБД среди российских компаний
Умение работать с СУБД PostgreSQL — база, которая точно не будет лишней. В бесплатном курсе от Selectel собрали все необходимое для погружения: от основ реляционной модели до создания таблиц и работы со сложными запросами. Вы актуальную теорию, практические задания и экономию десятков часов на самостоятельных поисках информации.
Курс подойдет как для первого знакомства с PostgreSQL, так и чтобы освежить и структурировать знания. Регистрируйтесь и начните обучение бесплатно
Реклама. АО "Селектел". erid:2W5zFJmnYQ9 | 714 |
| 8 |  Антипаттерн: «Одна таблица на всё»
Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды.
🔴 Что это такое?
Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где:
– сотни колонок на все случаи жизни,
– куча NULL-ов,
– смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы).
Так проще… пока не начнётся работа с реальными данными.
💥 Что пойдёт не так:
– Производительность падает: индексы не работают эффективно.
– Сложность валидации и бизнес-логики.
– Трудно расширять: каждое изменение — как операция на открытом сердце.
– Нельзя нормально нормализовать: всё связано со всем.
✅ Как избежать:
– Используй нормализацию: выноси повторяющиеся и логически независимые данные в отдельные таблицы.
– Не бойся JOIN-ов — это не зло, а инструмент.
– Планируй схему БД под задачи, а не наоборот.
📌 Пример:
Плохо:
CREATE TABLE everything (
id INT,
client_name TEXT,
order_price DECIMAL,
order_status TEXT,
delivery_address TEXT,
...
);
Хорошо:
CREATE TABLE clients (
id INT PRIMARY KEY,
name TEXT
);
CREATE TABLE orders (
id INT PRIMARY KEY,
client_id INT REFERENCES clients(id),
price DECIMAL,
status TEXT
);
📎 Вывод: одна таблица ≠ проще. Это короткий путь к хаосу.
Разделяй и властвуй.
Сохрани, чтобы не пришлось рефакторить через полгода 👇
📲 Мы в MAX
#db
👉 @database_info | 632 |
| 9 |  ❌ Антипаттерн: Хранить даты и время в VARCHAR
Встречали такое?
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
order_date VARCHAR(20)
);
На первый взгляд — всё ок: дата есть, строка хранит. Но на практике — сплошные проблемы:
🔴 Нет гарантии формата
'2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль.
🔴 Сложность фильтрации и сортировки
Сравнение строк ≠ сравнение дат.
Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо.
🔴 Нельзя использовать функции времени
Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают нормально с VARCHAR.
✅ Как правильно
Используйте типы DATE, TIMESTAMP, TIMESTAMPTZ — они:
* валидируют данные на вставке;
* дают мощный инструментарий для анализа;
* упрощают работу с часовыми поясами и интервалами.
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
order_date TIMESTAMPTZ DEFAULT now()
);
💡 Если данные приходят в виде строк — парси их при загрузке, а не храни как есть.
Сохрани, чтобы не наступить на эти же грабли ☝️
А как у вас хранят даты?
📲 Мы в MAX
#db
👉 @database_info | 736 |
| 10 |  🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу
Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить.
Основные типы индексов в PostgreSQL:
- B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN).
- Hash — только для поиска по точному равенству (=). Становится актуальным реже.
- GIN — для массивов, JSONB, полнотекстового поиска.
- GiST — геоданные, поиск по диапазонам, сложные типы.
- BRIN — для очень больших таблиц с упорядоченными данными (например, логи).
Практические советы:
- Не злоупотребляй индексами: каждый индекс замедляет INSERT/UPDATE/DELETE.
- Следи за актуальностью: периодически проверяй и удаляй неиспользуемые (pg_stat_user_indexes поможет).
- Составные индексы ((col1, col2)) эффективны, только если условия WHERE учитывают порядок колонок.
- Используй EXPLAIN ANALYZE, чтобы понять, работает ли индекс в реальности.
Типичная ошибка:
Создать индекс на всё подряд без анализа запросов. Итог — тормоза на записи и огромный размер базы.
✅ Индексы — это как специи: мало — пресно, много — несъедобно.
Вывод:
Хотите быструю базу — планируйте индексацию так же внимательно, как сами запросы.
Сохрани, чтобы не забыть!
📲 Мы в MAX
#db
👉 @database_info | 749 |
| 11 |  +3SQL Important Queries
Сохрани на потом, тебе пригодится👌
📲 Мы в MAX
#db
👉 @database_info | 1 138 |
| 12 |  Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL - partial indexes (частичные индексы).
Обычно мы создаём индексы на всю таблицу, но что если нам нужно ускорить только небольшую часть данных? Например, часто выбираются только активные пользователи (status = 'active'). Вместо полного индекса можно создать индекс только для нужного поднабора данных:
CREATE INDEX idx_active_users
ON users (last_login)
WHERE status = 'active';
Что это даёт:
- Индекс меньше по размеру → быстрее поиск и обновление.
- Используется только тогда, когда запрос соответствует условию status = 'active'.
- Меньше нагрузка на диск при обновлениях таблицы.
🛠 Где это реально помогает:
- Таблицы с миллионами записей, где активно работают только с частью строк.
- Сценарии "горячих" и "холодных" данных.
Рекомендую попробовать partial indexes там, где обычные индексы слишком тяжелы или тормозят обновления!
📲 Мы в MAX
#db
👉 @database_info | 1 178 |
| 13 |  Новые возможности – рядом! Теперь каждый может протестировать бесплатную «коробочную» версию объектного хранилища «S3 Архипелаг» 👨🏻💻
🚪Бесплатная версия снижает порог входа для проектов. Что нужно, чтобы начать? Просто скачайте дистрибутив, установите на свои серверы и приступите к работе сразу после авторизации через корпоративный SSO. Готово!
Сам «S3 Архипелаг» от Диасофт – российское S3-совместимое хранилище для работы с петабайтами данных в архитектурах Data Lakehouse, аналитических системах и консолидации разрозненных файловых хранилищ.
Оставляем ссылку на «S3 Архипелаг» 🔗
#реклама
О рекламодателе | 349 |
| 14 |  🚀 Сегодня я покажу вам один из моих любимых хаков для PostgreSQL – генерация серий дат без циклов и хранимок. Это идеальный способ быстро собрать таймлайн для аналитики или отчётов.
Сценарий: вам нужно построить список всех дат за последний месяц — например, чтобы потом сделать LEFT JOIN к таблице с событиями и увидеть, где были пропуски.
Вот как это делается с помощью generate_series:
SELECT generate_series(
date_trunc('day', current_date) - interval '30 days',
date_trunc('day', current_date),
interval '1 day'
) AS day;
💡 Результат — 31 строка с датами от 30 дней назад до сегодняшнего дня.
Теперь добавим, например, LEFT JOIN к таблице events, чтобы увидеть активность по дням:
SELECT
d.day,
COUNT(e.id) AS events_count
FROM
generate_series(
date_trunc('day', current_date) - interval '30 days',
date_trunc('day', current_date),
interval '1 day'
) AS d(day)
LEFT JOIN events e ON date_trunc('day', e.created_at) = d.day
GROUP BY d.day
ORDER BY d.day;
📊 Отлично подходит для дашбордов, когда нужно увидеть, где были дни без событий.
Пользуетесь ли вы generate_series? А может быть, используете что-то подобное в других СУБД? Делитесь в комментариях👇
📲 Мы в MAX
#db
👉 @database_info | 888 |
| 15 |  ⚡️ Совет по работе с базами данных 💡
Уникальные индексы с исключением определенных строк
Создание уникальных индексов в некоторых случаях невозможно из-за дублирования значений - например, в строках, помеченных как «мягко удаленные» (soft-deleted). Исключив такие строки из индекса, можно корректно настроить ограничение уникальности. В MySQL частичные уникальные индексы (unique partial indexes) требуют эмуляции.
В современных базах данных часто используется паттерн Soft Delete, когда данные не удаляются физически, а помечаются флагом is_deleted = true.
Если вы хотите, чтобы поле email было уникальным только для активных пользователей, обычный уникальный индекс выдаст ошибку при попытке регистрации нового пользователя с почтой, которая уже есть в «корзине». Использование частичного индекса решает эту проблему, позволяя игнорировать помеченные на удаление записи.
Нюанс для MySQL:
В отличие от PostgreSQL или SQL Server, MySQL не поддерживает синтаксис WHERE внутри команды CREATE INDEX. Чтобы добиться такого же поведения, разработчики обычно используют:
• Виртуальные колонки (Generated Columns): создается колонка, которая принимает значение только если запись активна, и на нее вешается уникальный индекс.
• Составные индексы: включение флага удаления или временной метки в сам индекс.
📲 Мы в MAX
#db
👉 @database_info | 780 |
| 16 | Как быстро найти “тяжёлые” запросы в 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 | 793 |
| 17 | 🚀 Сегодня покажу, как быстро диагностировать «тормоза» в 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;
Этот запрос покажет, кто кого блокирует, и с каким запросом.
🙌 Это простая, но мощная техника диагностики. Помогала мне не раз в проде - особенно, когда времени мало, а багов много.
Ты пользуешься pg_stat_activity в проде? Или сразу лезешь в лог? Расскажи в комментах!
📲 Мы в MAX
#db
👉 @database_info | 788 |
| 18 | 🧩 Как сделать 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 | 855 |
| 19 | 🎯 Сегодня покажу простой способ ускорить запросы в PostgreSQL, даже не трогая сам SQL-код.
Часто вижу, как разработчики и админы оптимизируют запросы, играя с индексами или переписывая JOIN'ы. Но забывают про один мощный инструмент — ANALYZE.
ANALYZE обновляет статистику по таблицам. Эта статистика — хлеб для планировщика запросов. Если она устарела, PostgreSQL может выбрать неэффективный план, даже если у вас всё индексировано как надо.
👨🔧 Простой пример:
ANALYZE my_big_table;
Запускаешь — и вдруг сложный JOIN срабатывает в разы быстрее. Потому что PostgreSQL теперь знает, какие там объемы данных, сколько уникальных значений в колонках и т.п.
🧠 Совет: если ты регулярно заливаешь данные в таблицы (например, через ETL или бэкапы) — добавь ANALYZE в конец процедуры. Это дёшево, но может дать мощный прирост производительности.
Можно даже так:
VACUUM ANALYZE my_big_table;
Так ты и "мусор" уберёшь, и статистику обновишь за один проход.
📲 Мы в MAX
#db
👉 @database_info | 911 |
| 20 |  Этот файл был удален пользователем
Встречаемся в Москве с теми, кто отвечает за хранение данных бизнеса. Обсудим, как решить задачу со звездочкой — уберечь массивы файлов и резервных копий от атак шифровальщиков, утечки или случайной перезаписи.
На бизнес-ужине эксперты провайдера ИТ-инфраструктуры Selectel расскажут:
➕как устроено хранилище S3 под капотом;
➕какие угрозы данным существуют и как выстроить многослойную систему защиты;
➕почему защита данных — это не статья расходов, а управление рисками.
Будет актуально руководителям в ИТ-компаниях, старшим архитекторам, системным администраторам. Поговорим и про стратегию хранения, и про реализацию.
📆 24 сентября (чт), 18:30
📍Москва, м. Динамо
⏩Участие бесплатное, дождитесь подтверждения заявки. Смотрите полную программу и регистрируйтесь: https://slc.tl/pophe
Реклама. АО "Селектел". erid:2W5zFG59449 | 835 |
