Есть ли какое-то преимущество в создании кластерного индекса - если мы не собираемся запрашивать / искать записи на основе этого столбца?
Я делаю обзор некоторых таблиц БД, которые были созданы в нашем проекте и натолкнулись на это. Таблица содержит столбец идентификатора (ID), который является первичным ключом таблицы, и кластерный индекс был определен с использованием этого столбца идентификатора. Но когда я смотрю на SPROC, который извлекает записи из этой таблицы, я вижу, что столбец ID никогда не используется в запросе, и они запрашивают записи на основе столбца USERID (этот столбец не является уникальным), и может быть несколько записей для тот же USERID.
Итак, у меня вопрос, есть ли преимущество / цель в создании кластерного индекса, когда мы знаем, что записи не будут запрашиваться с этим столбцом?
2 ответа
Я бы сказал, что ваш стол неправильно спроектирован. Кто-то, очевидно, думал, что каждой таблице нужен первичный ключ, а первичным ключом является кластерный индекс. Добавление сгенерированного системой уникального номера в качестве идентификатора просто добавляет шум, если этот номер нигде не используется. Шум в кластерном индексе бесполезен, если не сказать больше.
Кстати, это разные понятия. Первичный ключ - это проблема моделирования данных, логическая концепция. Индекс - это проблема физического проектирования. СУБД SQL должна поддерживать первичные ключи, но не должна иметь никаких индексов, кластеризованных или нет.
Если USERID это то, что обычно используется для поиска в таблице, оно должно быть в вашем кластеризованном индексе. Кластерный индекс не должен быть уникальным и не должен быть первичным ключом. Я хотел бы внимательно посмотреть на данные, чтобы увидеть, если какая-то комбинация USERID и другой столбец (или два, или более) образуют уникальный идентификатор строки. Если это так, я бы сделал это первичным ключом (и кластеризованным индексом), с USERID как первый столбец. Если анализ запросов показал, что многие запросы используют только USERID и ничего больше (для проверки существования) я мог бы создать отдельный индекс только USERID,
Если ни одна комбинация столбцов не составляет уникальный идентификатор, у вас возникает логическая проблема: что означает строка? Какой аспект реального мира он представляет?
Основной принцип реляционной модели состоит в том, что элементы отношения (строки в таблице) уникальны, каждый из них что-то идентифицирует. Если две строки идентичны, они идентифицируют одну и ту же вещь. Что значит удалить один из них? То, что они оба опознают, все еще там или нет? Если да, то какой цели служил 2-й ряд?
Я надеюсь, что это даст вам другой способ думать о кластерных индексах и ключах. Я не удивлюсь, если вы найдете другие таблицы, которые тоже можно улучшить.
Если IDENTITY столбец никогда не используется в WHERE а также JOIN пункты или ссылки на внешние ключи, возможно, USERID должен быть кластеризованным первичным ключом. Я бы поставил под сомнение необходимость столбца ID вообще в этом случае.
Лучший выбор для кластеризованного индекса во многом зависит от того, как запрашивается таблица. Если большинство запросов выполняется по USERID, то это, вероятно, должен быть уникальный кластеризованный индекс (или кластеризованное уникальное ограничение) и ID столбец некластеризованный.
Помните, что ключ кластеризованного индекса неявно включается во все некластеризованные индексы в качестве локатора строк. Подразумевается, что некластеризованные индексы в результате могут с большей вероятностью охватить запросы и страницы конечных узлов некластеризованного индекса.