---
aliases: 
tags:
  - зрелость/🌱
date:
  - - 2024-06-20
zero-link:
  - "[[00 Базы Данных]]"
  - "[[00 HighLoad]]"
parents: 
linked:
  - "[[Шардирование в БД]]"
---
## Тезисы
- Данные разделяются по какому-то признаку.
- Разделенные данные физически лежат раздельно. Разные таблицы. Но все данные остаются в пределах одного сервера.
- Прирост производительности будет только в том случае, если данные для выполнения запроса будут хранится в одной партиции. Поэтому важно правильно определить ключ партиционирования

***
На некоторых докладах партиции назывались вертикальным [шардированием](Шардирование%20в%20БД.md).

**Минусы:**
- Некоторые запросы могут замедлиться. Для выполнения запросов, в которых нам нужно сходить в несколько партиций.
- Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
- Перестройка партиций дорогостоящая операция.

**Плюсы:**
- Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
- Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.

**Основные типы разделения:**
- По ключу
- По диапазону
- По списку
- По хэш значению поля

**Советы:**
- Лучше не использовать BETWEEN для разбивки на партиции. Так как непонятно в какую партицию попадут пограничные значения
- Не стоит создавать партиции одной таблицы по разным полям.

Особенности СУБД:
- [Партиционирование в PostgreSQL](Партиционирование%20в%20PostgreSQL.md)
 
Пример создания в MySQL: ![](Pasted%20image%2020240620214648.png)