列はそれ自体を参照します。
したがって、行自体を追加すると、一致する行があることが保証されます。この制約は決して失敗することはありません。
実際、実行プランを見ると、SQL Serverはこれを認識しており、わざわざチェックすることさえありません。assert
オペレーターは存在しません。

より一般的なEmployeeテーブルを作成すると、以下のように制約に違反する可能性のある挿入のさまざまな計画があります。
create table EMP2(Eid int primary key, boss_id int null);
alter table EMP2 add constraint fk_EMP2_Eid
foreign key (boss_id) references EMP2(Eid)
insert into EMP2 values(1,null) /*Can't violate constraint as NULL*/
insert into EMP2 values(2,1) /*Can violate constraint as NOT NULL*/

複数の行を試すと、ブロックスプールがプランに追加されるため、すべての行が挿入されるまで制約はチェックされません。
insert into EMP2 values (3,2),(4,3) /*Can violate constraint - multiple rows*/

そして、コメントで提起された完全性のために、挿入が別のFKを参照しているテーブルへの挿入である場合を見てください...
CREATE TABLE EmpSalaryHistory
(
Eid INT NOT NULL REFERENCES EMP(Eid),
EffectiveDate DATETIME NOT NULL,
Salary INT,
PRIMARY KEY (Eid,EffectiveDate)
)
INSERT INTO EmpSalaryHistory
VALUES (1,GETDATE(),50000),
(2,GETDATE(),50000)
この場合、スプールはプランに追加されません。スプールは最後にすべてではなく各行を挿入するため、行が失敗した場合に早期にロールバックできるため、チェックできます(最終結果は同じになります)。
