2016-03-11 5 views
1

Я добавил столбец IDENTITY в существующую таблицу в SQL Server 2012. Ожидаемые числа, которые должны быть сгенерированы в порядке кластеризованного индекса (несекретный GUID), но, к моему удивлению, они были сгенерированы в порядке одного из индексов который даже не уникален, а также по совпадению точно так, как я хотел!Новый столбец IDENTITY на существующей таблице - какой порядок?

Может ли это объяснить это? Вот подробности таблицы:

id - guid (non-sequential), clustered index, primary key 
    eventdate - bigint (unix date), not null, non-unique index 
    more columns, some indexed, all indexes non-unique 

значения Удостоверения получили назначенные в порядке eventdate. Я даже нашел несколько примеров, когда несколько строк имели одинаковые eventdate, и у них всегда были последовательные идентификационные номера.

ответ

2

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

IDENTITY

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

Итак, вам лучше проверить, что вы получили новые значения IDENTITY в том порядке, в котором вы нуждаетесь. Проверьте все строки таблицы.

Редактировать

«Заказ не гарантируется» не означает, что он является случайным, это просто означает, что оптимизатор может свободно выбрать любой способ сканирования таблицы. В вашей системе он, видимо, выбрал этот индекс на eventdate (возможно, он имеет наименьшее количество страниц), но на другом оборудовании или другой версии сервера выбор может измениться, и вы не должны полагаться на него. Любое изменение структуры таблицы или индексов может также изменить выбор. Скорее всего, решение оптимизатора является детерминированным (т. Е. Не случайным), но оно не раскрывается в документах и ​​может зависеть от многих внутренних вещей и может измениться в любое время.

Ваш результат не является неожиданным. Значения идентичности были назначены в некотором неуказанном порядке, что совпало с порядком индекса.

+0

Спасибо, Владимир. Я действительно знал, что личный заказ не гарантирован - отсюда неожиданность, когда я добавлял и удалял столбец несколько раз, и каждый раз получал тот же неожиданный результат. Также я проверил каждую строку - я запустил запрос, который для каждой строки пытается найти другую строку, где идентификатор больше, а eventdate меньше. Запрос не дал никаких результатов. – Andrew

+0

@ Андрей, «заказ не гарантирован» не означает, что он случайный - см. Отредактированный ответ. –

 Смежные вопросы

  • Нет связанных вопросов^_^