Det effektivaste sättet att flytta tabellrader från en tabell till en annan

En annan lösning är att använda flera scheman och spela switch-a-roo. Jag föredrar bara den här metoden eftersom jag brukade göra det här tricket i ett jobb, och varningsmeddelandet om att byta namn på ett objekt (som inte kan undertryckas) fyllde upp mina historikloggar. I grund och botten behöver du två ytterligare scheman (ett för att hålla en kopia av tabellen tillfälligt och ett för att hålla den cachade kopian).

CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold  AUTHORIZATION dbo;

Skapa nu en efterlikning av tabellen i cacheschemat:

SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.

Nu när det är dags att uppdatera data:

-- step 1:
TRUNCATE TABLE cache.table;
-- (if you need to maintain FKs you may need to delete)
INSERT INTO cache.table SELECT ...

-- step 2:
-- this transaction will be almost instantaneous, 
-- since it is a metadata operation only: 

BEGIN TRANSACTION;
  ALTER SCHEMA hold  TRANSFER dbo.table;
  ALTER SCHEMA dbo   TRANSFER cache.table;
  ALTER SCHEMA cache TRANSFER hold.table;
COMMIT TRANSACTION;

Teoretiskt sett kan du flytta den sista överföringen från transaktionen, eftersom användare kunde börja fråga efter den nya kopian av dbo.table efter den andra överföringen, men som jag sa, detta är nästan omedelbart så jag skulle bli förvånad om du ser någon skillnad i samtidighet.

Du kan också valfritt trunkera cache.table igen här, men jag höll det alltid ifyllt så att jag kunde jämföra dataändringar eller felsöka om något gick fel. Beroende på hur lång tid -- steg 1 tar kan det vara snabbare att utföra överföringarna omvänt än att fylla i från början.

Som att byta namn, kan du få galna saker från den här processen, till exempel att statistik går vilse när de rör sig med det faktiska bordet, de håller inte med namnet. Och som byta namn, vill du testa detta och du kanske vill leka med isoleringsnivåer, t.ex. RCSI för åtkomst till rapporttabellen.