Какой индекс по умолчанию в PostgreSQL?

Типы индексов в PostgreSQL и значение "по умолчанию"

В PostgreSQL не существует единого "индекса по умолчанию", который создается автоматически для всех таблиц или первичных ключей. Однако, если говорить о наиболее часто используемом индексе, который PostgreSQL создает неявно в определенных сценариях, то это B-дерево (B-tree).

Когда вы создаете PRIMARY KEY или UNIQUE ограничение на столбец (или группу столбцов), PostgreSQL неявно создает уникальный индекс B-tree для поддержки этого ограничения. Это поведение делает B-дерево де-факто "индексом по умолчанию" в таких ситуациях, хотя технически это следствие объявления ограничения, а не автосоздания "просто так".

Подробное объяснение по умолчанию и B-tree

1. Создание PRIMARY KEY:

   CREATE TABLE users (
       id SERIAL PRIMARY KEY,  -- PostgreSQL автоматически создаст UNIQUE B-tree индекс для `id`
       name TEXT NOT NULL
   );
   

    Здесь индекс создается для:
    *   Гарантии уникальности значений `id`.
    *   Обеспечения быстрого поиска по первичному ключу (точного и диапазонного).
    *   Эффективных операций соединения (JOIN).

1. Создание UNIQUE ограничения:

   ALTER TABLE users ADD CONSTRAINT unique_email UNIQUE (email);
   -- Также создается уникальный B-tree индекс для столбца `email`
   

### Почему именно B-tree?

**B-tree (Balanced Tree, сбалансированное дерево)** — это структура данных, идеально подходящая для широкого спектра задач в СУБД. Он является "индексом по умолчанию" по умолчанию из-за своей универсальности:

*   **Поддержка различных типов запросов:**

*   **Точное совпадение:** `WHERE id = 5`.
*   **Диапазонные запросы:** `WHERE date BETWEEN '2023-01-01' AND '2023-12-31'`.
*   **Поиск по префиксу:** `WHERE name LIKE 'Ива%'` (для типов данных с естественным порядком).
*   **Сортировка (ORDER BY)** и **группировка (GROUP BY)**.
*   **Поиск `IS NULL` или `IS NOT NULL`** (в современных версиях PG).

*   **Эффективность для сортированных данных:** Данные в листьях дерева хранятся отсортированными, что ускоряет операции, требующие порядка.
*   **Хорошая сбалансированность:** Глубина всех ветвей дерева примерно одинакова, что гарантирует предсказуемую скорость доступа `O(log n)`.

### Другие типы индексов и их применение

PostgreSQL — мощная СУБД с множеством типов индексов (методов доступа). Выбор индекса **никогда не должен быть "по умолчанию"**, а всегда обосновываться паттернами запросов и типами данных.

| Тип индекса (метод доступа) | Ключевое назначение | Пример использования |
| :--- | :--- | :--- |
| **Hash** | **ТОЛЬКО** для операций равенства (`=`). Быстрее B-tree для простых точных совпадений, но не поддерживает диапазоны, сортировки и теряется при перезагрузке (до версии 10). | `SELECT * FROM table WHERE key = 'значение';` |
| **GIN (Generalized Inverted Index)** | Для индексирования **составных данных**: массивов (array), полнотекстового поиска (tsvector), JSONB. Оптимален для операций "содержит" (`@>`). | `SELECT * FROM products WHERE tags @> ARRAY['sale'];` |
| **GiST (Generalized Search Tree)** | Для **геоданных** (PostGIS), **полнотекстового поиска**, индексирования по **расстоянию**. Позволяет строить индексы для данных, где понятие "расстояния" определено. | `SELECT * FROM places WHERE location <-> point '(0,0)' < 10;` |
| **SP-GiST (Space-Partitioned GiST)** | Для неоднородных структур данных, таких как **древовидные структуры**, **IP-адреса**, **координаты**. | `SELECT * FROM networks WHERE ip <<= inet '192.168.1.0/24';` |
| **BRIN (Block Range INdexes)** | Для **очень больших таблиц**, где данные физически упорядочены на диске (например, по временной метке). Чрезвычайно компактный. | `SELECT * FROM sensor_data WHERE log_time >= '2023-10-01';` |

### Практические рекомендации и вывод

1.  **Осознанный выбор:** **Не полагайтесь на "индекс по умолчанию"**. При создании индекса явно указывайте тип, если он отличается от B-tree: `CREATE INDEX idx_name ON table USING gin (jsonb_column);`.
2.  **Для первичных ключей и уникальных ограничений** — **B-tree** действительно является автоматическим выбором и в большинстве случаев лучшим.
3.  **Анализируйте запросы (`EXPLAIN ANALYZE`):** Перед созданием индекса изучите план выполнения запроса. Индекс нужен только если его использует планировщик.
4.  **Составные индексы (multicolumn):** Порядок столбцов в B-tree индексе критически важен. Первый столбец должен фигурировать в условиях `WHERE` наиболее часто.
    ```sql
    -- Этот индекс полезен для запросов с условием по `a` и по `(a, b)`, но НЕ полезен для запросов только по `b`.
    CREATE INDEX idx_on_a_b ON my_table (a, b);
    ```

**Итог:** Хотя **B-tree** можно условно назвать "индексом по умолчанию" в контексте автоматического создания для `PRIMARY KEY` и `UNIQUE`, концептуально в PostgreSQL нет волшебного индекса, подходящего под все случаи. Сила PostgreSQL как раз в разнообразии **методов доступа (Access Methods)**, и правильный выбор индекса — это ключевой навык разработчика и администратора БД для построения производительных систем.