Сколько кластерных индексов можно добавить в таблицу?

Кластерные индексы в таблице: отвечаю на вопрос

Краткий ответ

В подавляющем большинстве систем управления базами данных (СУБД) на одну таблицу можно создать только один кластерный индекс. Это фундаментальное архитектурное ограничение, вытекающее из самой природы кластерного индекса.

Подробное объяснение

Кластерный индекс определяет физический порядок хранения данных на диске. Строки таблицы буквально "кластеризуются" (упорядочиваются) в соответствии со значениями ключа этого индекса.

-- В SQL Server создание кластерного индекса
CREATE CLUSTERED INDEX IX_EmployeeID 
ON Employees (EmployeeID);

Поскольку данные на физическом носителе могут быть организованы только одним способом (представьте страницы книги, которые можно отсортировать только по одному критерию), невозможно иметь два различных физических порядка для одной и той же таблицы. Если попытаться создать второй, СУБД выдаст ошибку.

Технические нюансы в разных СУБД

Хотя правило "один кластерный индекс на таблицу" универсально, есть важные особенности:

1. SQL Server
   • Только один кластерный индекс
   • Если не создан явно, СУБД может использовать кучу (heap) - таблицу без кластеризации
   • Первичный ключ по умолчанию создается как кластерный, но это можно изменить

-- Явное указание типа индекса для первичного ключа
ALTER TABLE Orders 
ADD CONSTRAINT PK_Orders 
PRIMARY KEY NONCLUSTERED (OrderID);

1. MySQL/InnoDB
   • Все таблицы InnoDB обязательно имеют кластерный индекс
   • Если явно не задан, используется:

     - Первичный ключ
     - Первый UNIQUE индекс с NOT NULL колонками
     - Скрытое 6-байтное поле ROWID

1. PostgreSQL
   • Терминология отличается: CLUSTER команда физически переупорядочивает таблицу по индексу, но это разовая операция
   • Постоянного кластерного индекса в стиле SQL Server нет
   • Можно создать индекс, похожий по функциям: CREATE INDEX ... INCLUDE (...) с покрывающими колонками

Обходные пути и рекомендации

Хотя нельзя иметь несколько кластерных индексов, можно эмулировать некоторые преимущества:

1. Некластерные индексы с включенными колонками

-- Создание покрывающего индекса
CREATE NONCLUSTERED INDEX IX_Employee_DeptDate
ON Employees (DepartmentID, HireDate)
INCLUDE (FirstName, LastName, Salary);

1. Индексированные представления (SQL Server)

   • Создание материализованного представления с кластерным индексом
   • Фактически создается отдельная структура с собственной кластеризацией

2. Партиционирование таблиц

   • Данные физически разделяются по партициям
   • Внутри каждой партиции действует свой порядок (если есть кластерный индекс)

Критерии выбора столбцов для кластерного индекса

Поскольку кластерный индекс единственный, его выбор критически важен:

• Уникальность - предпочтительно уникальные значения
• Узкий ключ - минимальный размер, так как ключ дублируется во всех некластерных индексах
• Статичность - избегайте часто изменяемых колонок
• Упорядоченность - естественный порядок прироста (IDENTITY, последовательности)
• Частые поиски/диапазоны - WHERE, JOIN, ORDER BY по этим колонкам

Практический пример

// Пример Entity Framework Core с явным указанием кластерного индекса
public class Order
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int OrderId { get; set; }
    
    public DateTime OrderDate { get; set; }
    public decimal TotalAmount { get; set; }
}

// В контексте OnModelCreating
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Создание кластерного индекса по OrderDate
    // (В реальности нужно учитывать последствия такого выбора!)
    modelBuilder.Entity<Order>()
        .HasIndex(e => e.OrderDate)
        .IsClustered();
    
    // Первичный ключ будет некластерным
    modelBuilder.Entity<Order>()
        .HasKey(e => e.OrderId)
        .IsClustered(false);
}

Вывод

Один кластерный индекс на таблицу - это не ограничение, а следствие физической организации данных. Правильный выбор столбцов для этого индекса - одно из важнейших решений при проектировании базы данных, значительно влияющее на производительность. В современных СУБД некластерные индексы с дополнительными функциями (включенные колонки, фильтрованные индексы) позволяют эффективно решать большинство задач, для которых теоретически мог бы понадобиться второй кластерный индекс.