Ответ
Кластерный индекс — это индекс, который определяет физический порядок хранения строк данных в таблице. Данные в таблице сортируются на диске в соответствии со значениями ключа этого индекса.
Ключевые особенности:
- Один на таблицу: Поскольку данные могут быть физически упорядочены только одним способом, в таблице может быть только один кластерный индекс.
- Высокая эффективность для диапазонных запросов: Запросы с
WHERE,ORDER BY,BETWEENпо ключу индекса выполняются быстрее, так как данные расположены последовательно. - Влияние на операции записи: Вставка, обновление или удаление строк может быть медленнее, если это требует физического перемещения данных для поддержания порядка.
Пример создания (SQL Server):
-- Создает кластерный индекс по столбцу EmployeeID.
-- Данные в таблице Employees будут физически отсортированы по EmployeeID.
CREATE CLUSTERED INDEX IX_Employees_EmployeeID ON Employees(EmployeeID);Практическое влияние:
- Первичный ключ (PRIMARY KEY) по умолчанию часто создается как кластерный индекс.
- Выбор правильного столбца для кластеризации (часто используемого в диапазонных запросах) критически важен для производительности.
Ответ 18+ 🔞
Да блядь, ну что за тема, а? Кластерный индекс! Сидишь такой, думаешь — ну индекс и индекс, хуй с ним. А вот нихуя! Это ж не просто какая-то там сортировка в голове у СУБД, это, сука, фундаментальный пиздец!
Представь себе полку с книгами. Можно, конечно, на каждой написать номер и сложить в коробку как попало, а потом искать по каталогу (это будет некластерный индекс, блядь). А можно взять и расставить их на полке строго по порядку этих номеров. Вот эта расстановка на полке — это и есть кластерный индекс, ёпта! Данные на диске лежат ровно в том же порядке, что и ключ индекса.
Основные фишки, от которых мозг вскипает:
- Один, блядь, и только один! Как ты физически-то книги расставишь в двух разных порядках одновременно? Вот и таблицу — нихуя. Одна полка — один порядок. Больше кластерных индексов не бывает.
- Для поиска "от сих до сих" — просто песня! Запрос типа
WHERE id BETWEEN 100 AND 200выполняется со скоростью света, потому что все эти строки лежат рядышком, одной кучей. Не нужно по всему диску скакать. - Но за всё надо платить, сука! Зато если ты вставляешь новую книгу с номером, который должен стоять в середине уже аккуратной полки... Всё, пиздец, начинается движуха: надо раздвинуть всё это добро, освободить место. Операции вставки/обновления могут ебнуть производительность конкретно так.
Вот смотри, как это объявляется (SQL Server):
-- Делаем так, чтобы все строки в таблице Employees
-- на диске лежали, отсортированные по EmployeeID.
-- Это и есть порядок на полке, блядь!
CREATE CLUSTERED INDEX IX_Employees_EmployeeID ON Employees(EmployeeID);А на практике что? Да почти всегда твой первичный ключ (PRIMARY KEY) по умолчанию и есть этот самый кластерный индекс, ёбта! И если ты, мудак, выберешь для него столбец с постоянно рандомными значениями (типа GUID), то при каждой вставке будет пиздец и движуха на полке. А если выберешь столбец, по которому часто ищут диапазоны (дата, например), то все запросы будут летать.
Короче, нехуй тут легкомысленно относиться. Выбрал неправильный столбец для кластеризации — и вся производительность накрылась медным тазом. Думай, блядь, думай головой!