Когда я обновляю строку в таблице SQL, как SQL точно обрабатывает обновление с точки зрения того, как оно перемещает данные? Я хотел бы предположить, что это поведение одинаково для кучи, а также кластеризованного индекса? Я спрашиваю об этом, потому что я хочу полностью понять поведение при попытке предотвратить появление фантомных строк. Они регулярно хранятся в нашем хранилище данных (сторонний инструмент, в котором мы застряли ..).
Я наткнулся на это утверждение на тренинге:
При сканировании всей таблицыSQL Server может решить выполнить сканирование порядка размещения (в порядке номеров страниц) вместо сканирования в логическом порядке (следуя указателям на страницы). Если другой процесс, выполняющий параллельные операции, изменяет данные и перемещает строки в новое место в таблице, сканирование порядка размещения может закончиться чтением одной и той же строки дважды.
Хорошо ... но почему :-)Между прочим, я ранее провёл несколько тестов (выбрал count (*) GO 100 и одновременно запустил оператор обновления для той же таблицы), и результат дал мне постоянное разное количество строк. (Авторы: Brent Ozar, кстати).
Я думал, что если SQL Server обновит строку, то данные в самой строке будут изменены, поэтому они не будут перемещаться в кластеризованном индексе или куче. Однако я читал вышеупомянутое утверждение и запутался в том, как это работает точно.
Я думаю, что это работает так:
SQL Server обновляет саму строку, поэтому строка остается ната же страницаОднако, если вставленные данные больше, чем уместились бы на странице, SQL Server выполняет разбиение страницы, и строка заканчивается на другой странице. Теперь, если строка остается на той же странице, проблем нет, но если она заканчивается на другой странице, то при выполнении этого сканирования порядка размещения вы можете в итоге прочитать одну и ту же строку дважды.
Так что в основноммой вопроскогда и особенно почему SQL Server перемещает строки при обновлении строки? Правильно ли мое предположение здесь?