Nano Hash - криптовалюты, майнинг, программирование

Когда использовать покрывающий индекс, составной индекс и уникальные столбцовые индексы

Допустим, у меня есть следующая таблица в SQL Server 2008:

ProfileID   int          //identity; index: unique, primary key, clustered
ClientID    int
RegionID    int
ProfileName nvarchar(50)

Столбцы 2 и 3 связаны с соответствующими таблицами внешними отношениями.

Скажем, мой самый распространенный запрос таков:

SELECT ProfileID, ProfileName
FROM   Profiles
WHERE  ClientID = ? AND RegionID = ?
ORDER  BY ProfileName

Какая система индексации лучше всего подходит?

Если я помещаю покрывающий индекс (ProfileID, ProfileName), то это убивает кластеризованный индекс по умолчанию, поскольку покрывающие индексы должны быть некластеризованными, но удовлетворяет, по крайней мере, возвращаемую часть запроса.

Если я оставлю первичный ключ как есть и независимо проиндексирую ClientID и RegionID, это даст мне 3 индекса, которые должны поддерживаться СУБД, ПЛЮС все равно потребуется сканирование таблицы для возврата ProfileName, поскольку оно не покрыто. Это кажется тяжелым.

Простой пример того, насколько сложным может быть планирование индексации.

sql-server database-design indexing rdbms
11.11.2010

Ответы:


1

Для этого запроса:

SELECT  ProfileID, ProfileName
FROM    Profiles
WHERE   ClientID = ? AND RegionID = ?
ORDER BY
        ProfileName

вы должны создать этот индекс:

CREATE INDEX ix_profiles_region_client_name ON (RegionID, ClientID, ProfileName)

В пределах одного значения (RegionID, ClientID) записи сортируются по ProfileName, так что записи будут отсортированы и никакой дополнительной сортировки не потребуется.

Поскольку ProfileID является PRIMARY KEY CLUSTERED, он неявно включается в каждую запись индекса, поэтому нет необходимости явно указывать его в определении индекса.

Если бы это был не кластеризованный ключ, вам нужно было бы добавить его в индекс, чтобы он охватывал этот запрос:

CREATE INDEX ix_profiles_region_client_name__id ON (RegionID, ClientID, ProfileName) INCLUDE (ProfileID)
11.11.2010
  • @Quassnoi, мой друг, ты вернулся. Я предполагаю, что вы имеете в виду ... и оставить первичный индекс тоже? Не только этот индекс? 11.11.2010
  • Quassnoi У меня есть два вопроса: 1) Я бы подумал, что (ClientID, RegionID...) будет лучше, поскольку ClientID является наиболее уникальным столбцом (хорошо, я не упомянул об этом в своем вопросе, конечно). Я так понимаю, порядок от наиболее уникального к наименее уникальному. Второй вопрос: почему ProfileName находится в индексе, а не как включенный столбец, когда мы не запрашиваем его специально? 11.11.2010
  • @Ianc: для этого самого запроса это не имеет большого значения, так как поиск всегда выполняется по всему кортежу (ClientID, RegionID). Однако вы можете изменить порядок, если вам нужно выполнить поиск только по ClientID (или в сочетании со столбцами, отличными от RegionID). ProfileName находится в индексе, потому что используется в предложении ORDER BY. Включенные столбцы не сортируются по индексу, поэтому запрос должен быть отсортирован, если вы включили ProfileName в качестве неключевого столбца. 11.11.2010
  • @Quassnoi Спасибо. Последний вопрос, если не возражаете. Если бы мне нужно было часто выполнять поиск либо по ClientID, либо по RegionID, был бы указанный вами индекс оптимальным? 11.11.2010
  • @IanC: лучше всего использовать два отдельных индекса: (ClientID, RegionID) и RegionID 11.11.2010
  • @Quassnoi хорошо, поэтому мы получим эти 2 (исключая очевидный основной): CREATE INDEX ix_profiles_region_client_name ON (RegionID, ClientID, ProfileName) CREATE INDEX ix_profiles_client_region ON (ClientID, RegionID) 11.11.2010
  • @IanC: нет необходимости добавлять RegionID во второй. Запросы на (ClientID, RegionID) будут обслуживаться первым. 11.11.2010
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..