Почему IDENTITY_INSERT ON допускается только для одной таблицы за раз?

Это тот случай, когда IDENTITY_INSERT может быть установлен только на ON в одной таблице базы данных одновременно, но почему? Поскольку IDENTITYстолбцы не являются глобально уникальными, я не могу вспомнить ни о какой опасной ситуации, которая могла бы быть вызвана вставкой идентификаторов в несколько таблиц одновременно (по крайней мере, не более опасно, чем в целом с использованием IDENTITY INSERT).

IDENTITY INSERT следует использовать редко, но в чем причина жесткого ограничения?

Я думаю, что это сделать это сложно. Если бы вы могли просто оставить его включенным все время, зачем вообще поле идентификации?

На самом деле есть пара ограничений:

• Это сохраняется только на этой связи
• Устанавливается только на одну таблицу для каждого соединения

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

Представьте, если кто-то включил вставку идентификатора в одну из ваших таблиц, то вы не поняли, и была выполнена (обычно) неверная вставка, которая нарушила целостность вашего поля идентификатора?

Имейте в виду, что поля идентификаторов могут иметь повторяющиеся значения, если нет ограничений или уникального индекса ...

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

Поскольку это параметр сеанса, разрешение активировать настройку для одной таблицы означает, что это простой флаг и идентификатор объекта таблицы для хранения в сеансе на стороне сервера. Может быть, это всего лишь одно целое число: 0, если IDENTITY_INSERT не активен, и некоторое кодирование databaseid + objectid для таблицы.

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

1. Это означает, что сервер выделил 1000 элементов в переменной сеанса
2. Это также означает, что сервер должен проверять список из 1000 элементов для каждого оператора вставки в этом сеансе.

Также я подозреваю, что set identity_insert имеет снижение производительности на сервере. В sybase существовал « коэффициент набора идентификаторов записи », который позволял сохранять значение счетчика идентификаторов таблицы, которая будет сохраняться только время от времени (значение сохраняется в памяти и время от времени записывается на диск и на сервер. неисправность ). SQL Server основан на том же коде, поэтому, вероятно, имеет некоторую сопоставимую оптимизацию, но активация identity_insert для таблицы, вероятно, заставляет сервер сохранять значение идентификатора для каждой вставки, поскольку в противном случае он не может гарантировать максимальный размер зазора. Поэтому, если один сеанс снижает производительность вставок в одной таблице, это, вероятно, приемлемо, но не в том случае, если он может повлиять на производительность всех таблиц auto_increment на сервере.