Вопросы Теги

Если я отбрасываю свой кластеризованный PK и добавляю новый, в каком порядке мои строки будут?

Я справился с сетевым аудитом европейских операций ОЧЕНЬ крупного производителя компьютеров (Ирландия Гм). Потребовались недели, но мы действительно обнаруживали, что каждый бит данных, которые впрыскивались вниз к каждому жесткому диску каждого ПК/сервера, который они сделали, перемещался через те же 4 потока провода - у них был единственный порт на 1 Гбит/с, делающий ВСЕ их сборки. Когда мы сказали им, что они РАБОТАЛИ для получения большего количества cable/SFPs и мультисоединили его каналом в течение 30 минут, но это было шокером.

4
задан 3 June 2010 в 19:28
4 ответа

При отбрасывании кластерного индекса, таблица становится "кучей". Так как "куча" имеет совсем другую физическую структуру от индексов, данные должны будут быть скопированы в новую структуру. "Куча" не имеет никакого порядка вообще. Когда Вы добавите назад новый кластерный индекс, данные будут скопированы с "кучи" в новый индекс, и порядок будет определен новым кластеризованным ключом.

Если Вы хотите сохранить существующий порядок затем все, что необходимо сделать, присваивают новые целочисленные идентификаторы правильно:

ALTER TABLE Table ADD Integer_Id INT;
GO

WITH cte AS (
  SELECT ROW_NUMBER() OVER (ORDER BY Guid_Id) as RowOrderByGuid,
    Guid_Id
  FROM Table)
UPDATE t
  SET t.Integer_Id = c.RowOrderByGuid
FROM Table t
JOIN cte c ON t.Guid_Id = c.Guid_Id;

Теперь порядок Integer_Ids будет соответствовать порядку Гуидов. Можно отбросить столбец Guid и добавить кластерный индекс на новом столбце Integer, и физический порядок записей был сохранен.

4
ответ дан 3 December 2019 в 02:34

По определению кластерный индекс налагает физическое упорядочивание на фактические страницы данных; таким образом, да, если Вы отбрасываете кластерный индекс и создаете новый, это вызовет физическое переупорядочение данных.

В Вашем случае я думаю, что безопасно предположить, что следующее произойдет:

  • Существующий кластерный индекс будет отброшен, но фактические данные по диску не собираются перемещаться из-за этого.
  • Вы измените тип столбца (или отбросите существующий столбец и создадите новый), устанавливая costraints, чтобы это не был пустой, уникальный, первичный ключ, идентификационные данные и автоувеличивающий (это жизненно важно, или SQL Server даже не позволит Вам добавить его, поскольку он не знал бы, что поместить в него).
  • На данном этапе столбец будет автоматически заполнен SQL Server. Я не знаю наверняка, что произойдет здесь, но я думаю, что это будет заполнено в строках порядка, phyically хранятся в базе данных. Но я просто предполагаю об этом.
  • Проблема, упорядочивание может быть довольно грязным, когда UIDs включены; таким образом, Вы не знаете, как данные на самом деле хранятся теперь, и Вы не знаете, как они будут сохранены позже; если мое предположение о населении столбца будет корректно, то не будет огромного переупорядочения..., но это могло произойти; и, даже если я корректен, индексное здание так или иначе собирается требовать времени, если таблица является достаточно большой.

Нижняя строка: Вы окажете огромное влияние, и Вы могли получить строки от незаказанного ВЫБОРА в том же порядке, Вы получаете их теперь. Необходимо будет попробовать.

3
ответ дан 3 December 2019 в 02:34

Кластерный индекс, по определению, определяет физический порядок данных, поэтому при создании нового кластерного индекса данные будут переупорядочены; если это - большая таблица, запланируйте это требовать времени.

2
ответ дан 3 December 2019 в 02:34
  • 1
    Прохладный that' s хороший для знания. Я думал, что индексы были, как SQL Server считал данные и не обязательно имение отношение к фактическому физическому местоположению его. I' m все еще довольно ограниченный в моем знании об индексах, таким образом, это было полезно. –  Sean Howat 3 June 2010 в 20:14
  • 2
    That' s верный для нормальных (некластеризованных) индексов; кластеризованный (может быть только один на таблицу), отличается точно поэтому. –  Massimo 3 June 2010 в 20:16

Если Вы составите таблицу с кластеризованным первичным ключом и затем отбросите кластеризованный PK, то физический порядок данных в таблице будет без помех. Однако физический порядок результатов запроса, как гарантируют, не совпадет с порядком в таблице, таким образом, это упорядочивание будет довольно бессмысленно.

Если Вы затем добавите целочисленный столбец и создадите кластеризованный первичный ключ на этом, то таблица будет перестроена в любой порядок сортировки по ключу в. Это может или не может быть тем же физическим порядком как GUID в зависимости от того, как ключ присвоен. Вы могли явно присвоить его на основе порядка сортировки ключа GUID (например, использующий row_number () по старому упорядочиванию ключа), или Вы могли присвоить ему некоторый другой путь. Если Вы не предпринимаете шаги, чтобы гарантировать, что упорядочивание явно сделано тем же, физический порядок или строки в таблице, как гарантируют, не будут управлять упорядочиванием Вашего нового ключа.

2
ответ дан 3 December 2019 в 02:34

Теги

Похожие вопросы