Назад | Перейти на главную страницу

Если я откажусь от кластерного ПК и добавлю новый, в каком порядке будут располагаться мои строки?

В SQL Server я смотрю на TableA, который в настоящее время имеет кластерный первичный ключ с уникальным идентификатором. GUID не имеет значения ни в каком контексте.

(Я дам вам секунду, чтобы очистить клавиатуру и монитор и поставить газировку.)

Я хотел бы удалить этот первичный ключ и добавить в таблицу новый уникальный целочисленный первичный ключ. Мой вопрос таков: когда я отбрасываю индекс, изменяю столбец с uniqueidentifier на int и добавляю новый кластеризованный уникальный первичный ключ в измененный столбец, будут ли новые значения PK располагаться в порядке вставки в таблицу или они будут быть в другом порядке? Это правильный путь сюда? Это сработает? (Я как бы новичок в создании / изменении таблиц.)

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

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

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 будет соответствовать порядку Guids. Вы можете отбросить столбец Guid и добавить кластеризованный индекс в новый столбец Integer, при этом физический порядок записей будет сохранен.

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

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

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

Итог: вы воля имеют огромное влияние, и вы мог получить строки из неупорядоченного SELECT в том же порядке, в котором вы их получили сейчас. Придется попробовать.

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

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

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