Индексы и вложенные множества - PullRequest
Новая
       9

Индексы и вложенные множества

6 голосов
/ 05 июля 2011

Я использую вложенный набор для представления иерархии в своем приложении, и мне интересно, где лучше всего разместить индексы (кластеризованные или нет). Я использую Microsoft SQL Server 2008.

Операции:

  1. Приблизительно 40 раз в день новая иерархия будет добавляться сразу после корня.
  2. Иерархии, вероятно, никогда не будут удалены.
  3. Доступ к иерархиям часто осуществляется в течение дня parentId для постепенного заполнения полей со списком.
  4. Иерархии ОЧЕНЬ редко перемещаются. Возможно, даже не один раз в месяц.
  5. Самый большой доступ через левый и правый при связывании с другими таблицами. Это, безусловно, самый частый доступ к иерархии.

Я играл с кластеризованным индексом слева и справа (в большинстве случаев он запрашивается с помощью val BETWEEN @left AND @right. Но является ли кластеризация слева и справа правильным способом?

Заранее большое спасибо всем, кто имеет больше опыта работы с индексами SQL, чем я!

Схема в ее нынешнем виде 

_id       INT IDENTITY NOT NULL
_idParent INT IDENTITY NULL
_name     NVARCHAR(64)
_left     INT NOT NULL
_right    INT NOT NULL

Ответы [ 2 ]

1 голос
/ 05 июля 2011

Лучше всего протестировать различные конфигурации индексов и посмотреть, какие из них работают лучше всего. Однако, на первый взгляд, кластеризация на lft и rgt кажется наилучшей. Похоже, в таблице не так много DML, поэтому не нужно слишком часто переставлять данные, а кластеризованный индекс по lft и rgt должен превратить большинство ваших запросов в просмотр / поиск кластеризованного индекса.

Единственный недостаток, который я вижу, заключается в том, что если вы размещаете иерархии прямо под корнем, то это может также включать перемещение многих других иерархий. Будете ли вы всегда добавлять на «правую» сторону корня? Это будет включать только обновление столбца rgt в корневой строке, что было бы хорошо. Если вы добавите в середину левой части корня, вам придется сместить все остальные иерархии справа от новой. Кроме того, насколько большой ваш стол? Это будет иметь некоторое влияние на вещи. Если он достаточно мал, то сдвиг этих иерархий может не иметь большого значения. Вы определенно хотите попробовать вставить правую сторону корня, если можете, хотя.

РЕДАКТИРОВАТЬ: Еще одна вещь ... вы смотрели во встроенный в SQL Server hierarchyid тип данных?

0 голосов
/ 06 июля 2011

Я бы нервничал по поводу использования кластерного индекса таким способом - он очень быстр для запросов, но любые операции вставки / обновления / удаления могут потребовать перезаписи данных на диск;это может создать серьезные проблемы с производительностью (особенно для больших таблиц).

Я бы также предположил, что на практике вы вряд ли заметите разницу между кластеризованным и некластеризованным индексом - особенно с целочисленными индексами,Если у вас есть гигантские таблицы - сотни миллионов записей - вы можете измерить разницу, но на современном оборудовании я не думаю, что это заметно.

ТАК, я бы согласился с Томом Х. - попробуй и измерить.Убедитесь, что вы измеряете вставку / обновление / удаление, а также запрос.Если вы не заметите действительно значительного выигрыша в производительности, я был бы склонен использовать кластеризованный индекс для первичного ключа - потому что по определению он неизменен.

...