Vilka är fördelarna med att använda Row Constructor-syntaxen i en T-Sql-infogningssats?

Ja, det är en ganska stor prestandaskillnad mellan:

declare @numbers table (n int not null primary key clustered);

insert into @numbers (n)
values (0)
     , (1)
     , (2)
     , (3)
     , (4);

och

declare @numbers table (n int not null primary key clustered);

insert into @numbers (n) values (0);
insert into @numbers (n) values (1);
insert into @numbers (n) values (2);
insert into @numbers (n) values (3);
insert into @numbers (n) values (4);

Det faktum att varje insert uttalande har sin egen implicita transaktion garanterar detta. Du kan enkelt bevisa det för dig själv genom att se exekveringsplanerna för varje påstående eller genom att tajma körningarna med set statistics time on; . Det finns en fast kostnad förknippad med att "sätta upp" och "riva ner" sammanhanget för varje enskilt bilaga och den andra frågan måste betala denna straffavgift fem gånger medan den första bara betalar den en gång.

Listmetoden är inte bara mer effektiv utan du kan också använda den för att bygga en härledd tabell:

select *
from (values
    (0)
  , (1)
  , (2)
  , (3)
  , (4)
) as Numbers (n);

Det här formatet kommer runt gränsen på 1 000 värden och låter dig gå med och filtrera din lista innan den infogas. Man kan också märka att vi inte är bundna till insert uttalande överhuvudtaget! Som en de facto-tabell kan denna konstruktion användas var som helst där en tabellreferens skulle vara giltig.