Хранилища данных
Транзакции | Введение | ACID | CAP | Обработка ошибок
Аномалии параллельных транзакций
Индексы SQL
Подготовка к собесу - Классификация баз данных
Подготовка к собесу - Оптимизация запросов
Подготовка к собесу - Подзапросы SQL и оптимизация
Подготовка к собесу - Индексы и партиции SQL
источник
Мы в MAX
#db
👉 @database_info
Транзакции | Введение | ACID | CAP | Обработка ошибок
Аномалии параллельных транзакций
Индексы SQL
Подготовка к собесу - Классификация баз данных
Подготовка к собесу - Оптимизация запросов
Подготовка к собесу - Подзапросы SQL и оптимизация
Подготовка к собесу - Индексы и партиции SQL
источник
Мы в MAX
#db
👉 @database_info
👍7❤2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Как лучше всего изучать язык SQL?
В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучить?
В состав языка SQL входят 5 компонентов:
Для бэкенд-инженера может потребоваться знание большинства из них. Аналитику данных может потребоваться хорошее понимание DQL. Выберите те темы, которые наиболее актуальны для вас.
Мы в MAX
#db
👉 @database_info
В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучить?
В состав языка SQL входят 5 компонентов:
- DDL: data definition language, such as CREATE, ALTER, DROP- DQL: data query language, such as SELECT- DML: data manipulation language, such as INSERT, UPDATE, DELETE- DCL: data control language, such as GRANT, REVOKE- TCL: transaction control language, such as COMMIT, ROLLBACKДля бэкенд-инженера может потребоваться знание большинства из них. Аналитику данных может потребоваться хорошее понимание DQL. Выберите те темы, которые наиболее актуальны для вас.
Мы в MAX
#db
👉 @database_info
🔥8👍1
Безумные и забавные факты о SQLite
⚫️ SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.
⚫️ Её поддерживают три человека. Они не допускают внешних контрибьюторов.
Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду.
https://habr.com/ru/companies/ruvds/articles/873816/
Мы в MAX
#db
👉 @database_info
Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду.
https://habr.com/ru/companies/ruvds/articles/873816/
Мы в MAX
#db
👉 @database_info
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9
База данных PostgreSQL
Часть 1. Установка и настройка
Часть 2. Язык запросов SQL
Часть 3. Реляционная модель
Часть 4. Поиск и анализ данных
Часть 5. Индексы
источник
Мы в MAX
#db
👉 @database_info
Часть 1. Установка и настройка
Часть 2. Язык запросов SQL
Часть 3. Реляционная модель
Часть 4. Поиск и анализ данных
Часть 5. Индексы
источник
Мы в MAX
#db
👉 @database_info
1👍5❤3🔥2
Media is too big
VIEW IN TELEGRAM
NoSQL для начинающих на примере MongoDB
00:00 - Что такое NoSQL и где он применяется?
04:18 - Основные виды NoSQL
06:04 - Дополнительные темы
09:31 - SQL vs NoSQL
11:53 - Немного о MongoDB
14:37 - Практика. Моделирование структуры. Работа с shell и Compass
Мы в MAX
#db
👉 @database_info
00:00 - Что такое NoSQL и где он применяется?
04:18 - Основные виды NoSQL
06:04 - Дополнительные темы
09:31 - SQL vs NoSQL
11:53 - Немного о MongoDB
14:37 - Практика. Моделирование структуры. Работа с shell и Compass
Мы в MAX
#db
👉 @database_info
1👍3❤1
Храните данные ближе к клиентам 📩
Разверните файловые хранилища, медиасерверы, большие архивы данных и системы аналитики на сервере-хранилище от Selectel в Новосибирске.
Отличное решение, если:
📍вы работаете с проектами из Сибири и с Дальнего Востока,
📍вам важна географическая распределенность.
Закажите сервер SL108R в Selectel и храните данные там, где удобно:
https://slc.tl/y00o0?erid=2W5zFHha3qr
Разверните файловые хранилища, медиасерверы, большие архивы данных и системы аналитики на сервере-хранилище от Selectel в Новосибирске.
Отличное решение, если:
📍вы работаете с проектами из Сибири и с Дальнего Востока,
📍вам важна географическая распределенность.
Закажите сервер SL108R в Selectel и храните данные там, где удобно:
https://slc.tl/y00o0?erid=2W5zFHha3qr
🚀 Оптимизация запросов в SQL: как не утонуть в данных
Сегодня хочу поделиться мыслями на тему, которая часто становится болью для многих разработчиков баз данных — оптимизация SQL-запросов.
Когда база данных растёт, а запросы становятся сложнее, даже небольшой промах может привести к тому, что ваш сервер начнёт "плакать" под нагрузкой. Вот несколько советов, которые помогут вам держать запросы в тонусе:
1. Индексы — ваш лучший друг (и враг, если использовать неправильно)
Индексы ускоряют поиск данных, но их избыток может замедлить вставку и обновление. Используйте их с умом:
- Индексируйте только те столбцы, которые часто используются в условиях
- Избегайте индексов на столбцах с низкой селективностью (например, пол с значениями "М" и "Ж").
2. Анализируйте план выполнения запроса
Перед тем как оптимизировать, нужно понять, что именно тормозит. Используйте
- Полноценные сканирования таблиц (
- Вложенные циклы (
- Использование временных таблиц и сортировок.
3. Избегайте N+1 проблемы
Если вы работаете с ORM, убедитесь, что не делаете лишних запросов. Например, вместо того чтобы выбирать связанные данные в цикле, используйте
4. Кэшируйте то, что можно кэшировать
Не все данные нужно каждый раз запрашивать из базы. Используйте кэширование для часто запрашиваемых данных. Redis или Memcached — отличные инструменты для этого.
5. Нормализация — это хорошо, но не всегда
Нормализация базы данных помогает избежать дублирования данных, но иногда денормализация может значительно ускорить запросы. Например, если у вас есть сложные агрегации, подумайте о создании материализованных представлений.
6. Следите за статистикой
Базы данных часто используют статистику для оптимизации запросов. Убедитесь, что она актуальна. Например, в PostgreSQL можно обновить статистику с помощью команды
7. Не забывайте про мониторинг
Используйте инструменты для мониторинга производительности базы данных, такие как pg_stat_activity в PostgreSQL или Performance Schema в MySQL. Это поможет вовремя выявить "узкие" места.
Мы в MAX
#db
👉 @database_info
Сегодня хочу поделиться мыслями на тему, которая часто становится болью для многих разработчиков баз данных — оптимизация SQL-запросов.
Когда база данных растёт, а запросы становятся сложнее, даже небольшой промах может привести к тому, что ваш сервер начнёт "плакать" под нагрузкой. Вот несколько советов, которые помогут вам держать запросы в тонусе:
1. Индексы — ваш лучший друг (и враг, если использовать неправильно)
Индексы ускоряют поиск данных, но их избыток может замедлить вставку и обновление. Используйте их с умом:
- Индексируйте только те столбцы, которые часто используются в условиях
WHERE, JOIN и ORDER BY. - Избегайте индексов на столбцах с низкой селективностью (например, пол с значениями "М" и "Ж").
2. Анализируйте план выполнения запроса
Перед тем как оптимизировать, нужно понять, что именно тормозит. Используйте
EXPLAIN (или EXPLAIN ANALYZE в PostgreSQL) для анализа плана выполнения. Обратите внимание на: - Полноценные сканирования таблиц (
Seq Scan). - Вложенные циклы (
Nested Loop), которые могут быть медленными на больших данных. - Использование временных таблиц и сортировок.
3. Избегайте N+1 проблемы
Если вы работаете с ORM, убедитесь, что не делаете лишних запросов. Например, вместо того чтобы выбирать связанные данные в цикле, используйте
JOIN или prefetch_related (в Django). 4. Кэшируйте то, что можно кэшировать
Не все данные нужно каждый раз запрашивать из базы. Используйте кэширование для часто запрашиваемых данных. Redis или Memcached — отличные инструменты для этого.
5. Нормализация — это хорошо, но не всегда
Нормализация базы данных помогает избежать дублирования данных, но иногда денормализация может значительно ускорить запросы. Например, если у вас есть сложные агрегации, подумайте о создании материализованных представлений.
6. Следите за статистикой
Базы данных часто используют статистику для оптимизации запросов. Убедитесь, что она актуальна. Например, в PostgreSQL можно обновить статистику с помощью команды
ANALYZE. 7. Не забывайте про мониторинг
Используйте инструменты для мониторинга производительности базы данных, такие как pg_stat_activity в PostgreSQL или Performance Schema в MySQL. Это поможет вовремя выявить "узкие" места.
Мы в MAX
#db
👉 @database_info
👍7
👍9🔥5❤1
🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения?
🛠 Основные проблемы:
🔹 Чрезмерное количество
🔹 Неправильные индексы – или их отсутствие вообще.
🔹 Подзапросы вместо
🔹 Ненужные
🔹 Фильтрация после
✅ Как ускорить запрос?
1️⃣ Проверьте индексы – используйте
2️⃣ Разбейте сложный запрос на части – иногда лучше записать результат во временную таблицу.
3️⃣ Избегайте
4️⃣ Используйте
5️⃣ Тестируйте с разными
6️⃣ Оптимизируйте сортировку –
Мы в MAX
#db
👉 @database_info
🛠 Основные проблемы:
🔹 Чрезмерное количество
JOIN – могут приводить к тяжелым вычислениям. 🔹 Неправильные индексы – или их отсутствие вообще.
🔹 Подзапросы вместо
JOIN – иногда работают хуже, чем соединения. 🔹 Ненужные
SELECT * – выбираем только нужные колонки. 🔹 Фильтрация после
JOIN – фильтруем данные как можно раньше. ✅ Как ускорить запрос?
1️⃣ Проверьте индексы – используйте
EXPLAIN перед выполнением запроса. Если сканируется весь таблица (Full Table Scan), значит, нужны индексы. 2️⃣ Разбейте сложный запрос на части – иногда лучше записать результат во временную таблицу.
3️⃣ Избегайте
SELECT * – указывайте только нужные колонки. 4️⃣ Используйте
EXISTS вместо IN – в подзапросах это часто работает быстрее. 5️⃣ Тестируйте с разными
JOIN – попробуйте INNER JOIN, LEFT JOIN, а в некоторых случаях UNION. 6️⃣ Оптимизируйте сортировку –
ORDER BY без индексов тормозит запрос. Мы в MAX
#db
👉 @database_info
👍5❤4
Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀
Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся!
🔹 Миф: индексы всегда ускоряют запросы
На самом деле, индекс может даже замедлить выполнение, если:
✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы.
✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице.
✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE.
🔹 Как правильно анализировать?
Используйте
🔍 Используется ли индекс?
🔍 Сколько строк проходит сканирование?
🔍 Есть ли операции сортировки, которые можно избежать с индексом?
🔹 Что делать, если запрос медленный?
1️⃣ Проверить план выполнения (не добавлять индекс вслепую!).
2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям.
3️⃣ Проверить, можно ли избежать сортировки (
4️⃣ Рассмотреть материализованные представления для сложных агрегатов.
Мы в MAX
#db
👉 @database_info
Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся!
🔹 Миф: индексы всегда ускоряют запросы
На самом деле, индекс может даже замедлить выполнение, если:
✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы.
✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице.
✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE.
🔹 Как правильно анализировать?
Используйте
EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания: 🔍 Используется ли индекс?
🔍 Сколько строк проходит сканирование?
🔍 Есть ли операции сортировки, которые можно избежать с индексом?
🔹 Что делать, если запрос медленный?
1️⃣ Проверить план выполнения (не добавлять индекс вслепую!).
2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям.
3️⃣ Проверить, можно ли избежать сортировки (
ORDER BY по индексу). 4️⃣ Рассмотреть материализованные представления для сложных агрегатов.
Мы в MAX
#db
👉 @database_info
👍5❤4
🔥 Оптимизация SQL-запросов: 5 ключевых техник
Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀
1️⃣ Используйте индексы
Индексы – это ускоритель запросов. Если у вас часто выполняются
2️⃣ Избегайте
Выбирайте только нужные столбцы.
3️⃣ Нормализация или денормализация?
Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию!
4️⃣ Кеширование запросов
Если запрос выполняется часто и данные редко меняются, используйте
5️⃣ Анализируйте планы выполнения
Команда
💡 Используете ли вы эти техники? Напишите, какой метод вам помог ускорить работу БД!
Мы в MAX
#db
👉 @database_info
Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀
1️⃣ Используйте индексы
Индексы – это ускоритель запросов. Если у вас часто выполняются
WHERE, JOIN или ORDER BY по определенному столбцу – создайте для него индекс. Но не переборщите: индексы ускоряют чтение, но замедляют вставку и обновление данных. 2️⃣ Избегайте
SELECT * Выбирайте только нужные столбцы.
SELECT * может загружать ненужные данные и нагружать сервер. Лучше указывать конкретные столбцы. 3️⃣ Нормализация или денормализация?
Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию!
4️⃣ Кеширование запросов
Если запрос выполняется часто и данные редко меняются, используйте
QUERY CACHE или внешние кеширующие механизмы (Redis, Memcached). 5️⃣ Анализируйте планы выполнения
Команда
EXPLAIN в MySQL/PostgreSQL покажет, как СУБД выполняет запрос. Это поможет найти узкие места: медленные JOIN'ы, сканы всей таблицы и т.д. 💡 Используете ли вы эти техники? Напишите, какой метод вам помог ускорить работу БД!
Мы в MAX
#db
👉 @database_info
👍6❤1
Как эффективно работать с датами в SQL?
Привет, друзья! Сегодня разберем один из самых частых вопросов в SQL — работу с датами. Даты встречаются везде: в заказах, логах, отчетах. И если их неправильно хранить или использовать, можно напороться на серьезные проблемы с производительностью и логикой запросов.
Вот несколько ключевых моментов:
🔹 Используйте правильный тип данных
Не храните даты в
🔹 Не используйте
Запрос вида:
может привести к тому, что индексы не будут использоваться. Лучше заранее вычислить диапазон и передать его в запрос.
🔹 Сравнение по диапазону – ключ к оптимизации
Для фильтрации по дате лучше использовать BETWEEN:
Это более понятно и эффективно.
🔹 Осторожно с часовыми поясами
Если ваш сервис работает глобально, храните время в
🔹 Агрегируйте правильно
Часто нужно сгруппировать данные по дням или месяцам:
Но если поле
Работа с датами — мощный инструмент, но требует внимательности. Как вы решаете проблемы с обработкой времени в SQL? Делитесь в комментариях!
Мы в MAX
#db
👉 @database_info
Привет, друзья! Сегодня разберем один из самых частых вопросов в SQL — работу с датами. Даты встречаются везде: в заказах, логах, отчетах. И если их неправильно хранить или использовать, можно напороться на серьезные проблемы с производительностью и логикой запросов.
Вот несколько ключевых моментов:
🔹 Используйте правильный тип данных
Не храните даты в
VARCHAR! Всегда используйте DATE, DATETIME или TIMESTAMP. Это не только экономит место, но и ускоряет запросы. 🔹 Не используйте
NOW() в WHERE без обработки Запрос вида:
SELECT * FROM orders WHERE order_date > NOW() - INTERVAL 7 DAY;
может привести к тому, что индексы не будут использоваться. Лучше заранее вычислить диапазон и передать его в запрос.
🔹 Сравнение по диапазону – ключ к оптимизации
Для фильтрации по дате лучше использовать BETWEEN:
SELECT * FROM orders WHERE order_date BETWEEN '2024-02-01' AND '2024-02-07';
Это более понятно и эффективно.
🔹 Осторожно с часовыми поясами
Если ваш сервис работает глобально, храните время в
UTC и конвертируйте на уровне приложения. 🔹 Агрегируйте правильно
Часто нужно сгруппировать данные по дням или месяцам:
SELECT DATE(order_date) AS order_day, COUNT(*) FROM orders GROUP BY order_day;
Но если поле
order_date – DATETIME, такие операции могут игнорировать индексы. Лучше использовать GROUP BY DATE_FORMAT(order_date, '%Y-%m-%d') или завести отдельное DATE-поле. Работа с датами — мощный инструмент, но требует внимательности. Как вы решаете проблемы с обработкой времени в SQL? Делитесь в комментариях!
Мы в MAX
#db
👉 @database_info
👍14
🔥 Шпаргалка по SQL с основными командами и примерами
1. Основные команды SQL
2. Фильтрация данных (WHERE, AND, OR, LIKE, IN, BETWEEN)
3. Группировка и агрегатные функции (GROUP BY, HAVING, COUNT, SUM, AVG, MAX, MIN)
4. Сортировка (ORDER BY)
5. Соединение таблиц (JOIN)
6. Создание и изменение таблиц (CREATE, ALTER, DROP)
7. Работа с индексами (INDEX)
8. Ограничения (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, DEFAULT)
9. Подзапросы (SUBQUERY)
10. Транзакции (BEGIN, COMMIT, ROLLBACK)
Мы в MAX
#db
👉 @database_info
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
); -- Создание таблицы
ALTER TABLE users ADD COLUMN email VARCHAR(100); -- Добавление колонки
ALTER TABLE users DROP COLUMN email; -- Удаление колонки
DROP TABLE users; -- Удаление таблицы
7. Работа с индексами (INDEX)
CREATE INDEX idx_users_name ON users(name); -- Создание индекса
DROP INDEX idx_users_name; -- Удаление индекса
8. Ограничения (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, DEFAULT)
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
user_id INT REFERENCES users(id), -- Внешний ключ
amount DECIMAL(10,2) CHECK (amount > 0), -- Ограничение CHECK
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP -- Значение по умолчанию
);
9. Подзапросы (SUBQUERY)
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);
10. Транзакции (BEGIN, COMMIT, ROLLBACK)
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- Завершение транзакции
ROLLBACK; -- Откат изменений
Мы в MAX
#db
👉 @database_info
👍7🔥6❤1
🔥 Оптимизация запросов: Как убрать тормоза в SQL?
Сейчас покажу вам, как ускорить медленный SQL-запрос, который выполняется слишком долго. Если у вас в проекте есть запросы, которые выполняются секундами, а не миллисекундами, пора что-то менять!
🚀 Разбор примера
Допустим, у нас есть такой запрос:
Кажется простым, но выполняется медленно. В чём может быть проблема?
📌 Основные причины тормозов:
1️⃣ Нет нужного индекса – если
2️⃣ Слишком много данных – если таблица огромная,
3️⃣ Использование
✅ Как ускорить?
✔ Добавляем индекс (если его нет):
✔ Выбираем только нужные колонки:
✔ Лимитируем выборку (если нужен только последний заказ):
🔥 Итог
Добавление индекса + правильный выбор колонок +
А какие приёмы оптимизации запросов используете вы? Делитесь в комментариях!
📲 Мы в MAX
#db
👉 @database_info
Сейчас покажу вам, как ускорить медленный 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 = в разы быстрее! 🚀 А какие приёмы оптимизации запросов используете вы? Делитесь в комментариях!
#db
👉 @database_info
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤1
🔥 Оптимизация индексов: частая ошибка DBA 🔥
Сегодня разберём распространённую ошибку, которую совершают многие администраторы баз данных — избыточные индексы.
💡Проблема
Добавление индексов — это полезно, но если их становится слишком много, то база данных начинает тормозить при вставке, обновлении и удалении данных. Почему? Потому что каждый индекс требует дополнительного обслуживания при изменениях в таблице.
💡Пример ошибки
Представим таблицу
Допустим, мы добавляем индексы:
На первый взгляд, всё логично, но есть проблема: индекс
💡Как исправить?
Можно удалить
📌 Как проверить ненужные индексы?
1️⃣ В PostgreSQL:
2️⃣ В MySQL:
Здесь ищем индексы, которые дублируют друг друга.
Вывод: Чем меньше избыточных индексов — тем быстрее работает ваша база данных. Проверьте свои индексы прямо сейчас!
📲 Мы в MAX
#db
👉 @database_info
Сегодня разберём распространённую ошибку, которую совершают многие администраторы баз данных — избыточные индексы.
💡Проблема
Добавление индексов — это полезно, но если их становится слишком много, то база данных начинает тормозить при вставке, обновлении и удалении данных. Почему? Потому что каждый индекс требует дополнительного обслуживания при изменениях в таблице.
💡Пример ошибки
Представим таблицу
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;
Здесь ищем индексы, которые дублируют друг друга.
Вывод: Чем меньше избыточных индексов — тем быстрее работает ваша база данных. Проверьте свои индексы прямо сейчас!
#db
👉 @database_info
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9