Pull to refresh

Comments 9

А как бы выглядел обычный индекс для кучи?
Я планировал для кучи отдельную статью, поскольку это — одна из незаслуженно забытых структур. Да и деталей там немало (например, для в зависимости от уникальности индекса), но если коротко, то индексы будут содержать адреса FID:PID:SID, где SID — номер слота.
Спасибо за статью.
Теперь ясней понимаю как размер NONCLUSTERED INDEX зависит от того какой тип данных выбран для CLUSTERED INDEX.

Я думаю вместо Value надо поставить А?
  CREATE INDEX [IX_ClusteredTable] 
  ON [dbo].[ClusteredTable] ([A] ASC)

Да, совершенно верно. Спасибо, поправил.
Замечательная статья, но В-дерево — это не бинарное дерево.
Спасибо. Внутри там, правда, самый натуральный BST, но в моей формулировке прозвучало как знак равенства, что не верно.
А можно попросить ещё написать статью с примерами хитрых кейсов по оптимизации.
Когда, например, пересортировка полей в запросе или индексе дает заметный результат.

Ещё интересует вопрос, у нас есть таблица к которой летит 10 тыс. запросов подряд, каждый из них довольно быстрый, но но из-за суммарного количества, запросы отрабатывают секунд за 6. Что можно придумать в такой ситуации на стороне базы или конекшен пула?
Я с таких статей и планировал начать, но понял, что нужно подготовить некоторую базу. Что до вопроса, то я бы начал с просмотра wait statistics. Она как раз собирает «простои» по всем запросам.
>> два уровня. А их могли бы быть десятки и сотни
Пардон за занудство, у Вас небольшая неточность, сотни уровней — это вряд ли.
Сбалансированное дерево означает, что любой узел на непоследнем уровне имеет, как минимум, два подузла.
Следовательно, 200 уровней, это минимум 2**199+2 страниц * 8К = 2**212+2 > 4*10**63 байт. Сравните, по оценкам Cisco, объем мирового трафика, направляемый в ЦОД в 2018г. достигнет всего лишь 8 зеттабайт = 2**83 байт.
Sign up to leave a comment.

Articles