IDENTITY_INSERT ONが一度に1つのテーブルでしか許可されないのはなぜですか？

これは、というケースですIDENTITY_INSERTが一度に一つのデータベーステーブルにONにのみ設定することができますが、なぜですか？IDENTITY列はグローバルに一意ではないため、複数のテーブルに同時にIDを挿入することによって引き起こされる危険な状況は考えられません（少なくともIDENTITY INSERTを使用するよりも危険ではありません）。

IDENTITY INSERTはめったに使用されるべきではありませんが、ハードリミットの理由は何ですか？

難しくすることだと思います。いつでもそのままにしておくことができるのであれば、なぜIDフィールドさえ持っているのでしょうか？

ただし、実際にはいくつかの制限があります。

• その接続でのみ持続します
• 接続ごとに1つのテーブルでのみ設定可能

接続に関連した制限に基づいて、私はそれが主にそうであると思うので、それは決して誤ってオンのままにされません。

誰かがあなたのテーブルのいずれかでID挿入をオンにした場合、あなたは気づかず、（通常）無効な挿入が実行され、IDフィールドの整合性が壊れたと想像してください。

制約または一意のインデックスが設定されていない場合、IDフィールドには重複した値が含まれることがあることに注意してください...

私の推測では、これは実装による制限でした。複数のテーブルでこの設定を許可すると、パフォーマンスが低下する可能性がありました。

これはセッションパラメータであるため、設定を単一のテーブルで有効にできるということは、単純なフラグと、サーバー側のセッションに保存するテーブルのオブジェクトIDであることを意味します。たぶん、これは単一の整数です：IDENTITY_INSERTがアクティブでない場合は0、テーブルのdatabaseid + objectidのコーディング。

セッション内の複数のテーブルにパラメータを設定できるようにすると、サーバーはそのようなオブジェクトの動的リストを保存し、すべての挿入ステートメントをチェックします。セッションが1,000個のテーブルのパラメーターをアクティブにすることを想像してください。

1. これは、サーバーがセッション変数に1000個のアイテムを割り当てたことを意味します
2. これは、サーバーがこのセッションのすべての挿入ステートメントについて1000項目のリストを確認する必要があることも意味します。

また、identity_insertをonに設定すると、サーバーでパフォーマンス全体のパフォーマンスが低下する可能性があります。sybaseには、「ID書き込みセットファクター」があり、テーブルのIDカウンターの値を一度だけ保存することができました（値はメモリに保持され、たまにサーバーに書き込まれますシャットダウン ）。SQL Serverは同じコードに基づいているため、おそらく同等の最適化が行われますが、テーブルでidentity_insertをアクティブにすると、サーバーがすべての挿入のID値を保存するように制約される可能性があります。したがって、1つのセッションが1つのテーブルの挿入でパフォーマンスヒットした場合、これはおそらく受け入れられますが、サーバー上のすべてのauto_incrementテーブルでperfヒットできる場合はそうではありません。