禁用索引和刪除約束並重建 SQL Server 表的最快方法

下面是我們在具有數十億條記錄的表上執行的一些 T-SQL 命令。數據庫的大部分大小都被這樣的 5 個表佔用。在不引起任何問題的情況下執行這些步驟的最快方法是什麼？執行第一個命令需要一個多小時。刪除整個表並重新創建它會更容易嗎？或者，有這麼多數據是不可能和安全的嗎？誰能想到任何其他想法來加快速度？我們只是試圖截斷數據，然後在我們的 ETL 過程中從頭開始重建表。

       DROP INDEX [OF_IDX_ClusteredConcept] ON [dbo].[OBS_FACT] WITH ( ONLINE = OFF )
       ALTER TABLE OBS_FACT DROP CONSTRAINT OBS_FACT_PK
       ALTER INDEX ALL ON OBS_FACT disable;

       -- add new data to OBS_FACT table via ETL process

       ALTER TABLE [dbo].[OBS_FACT] ADD CONSTRAINT [OBS_FACT_PK] PRIMARY KEY NONCLUSTERED 
       (
           [ENCOUNTER_NUM] ASC,
           [CONCEPT_CD] ASC,
           [PROVIDER_ID] ASC,
           [START_DATE] ASC,
           [MODIFIER_CD] ASC,
           [INSTANCE_NUM] ASC
       ) ON [PRIMARY]

       CREATE CLUSTERED INDEX [OF_IDX_ClusteredConcept] ON [dbo].[OBS_FACT] 
       (
           [CONCEPT_CD] ASC
       );  

       -- REBUILD indexes on OBSERVATION_FACT
       ALTER INDEX ALL ON OBS_FACT REBUILD

通常，如果您嘗試在不同的視窗中重新啟動 SQL Server Management Studio，則 drop index 命令會在 SQL Server Management Studio 中導致此錯誤。

超過鎖定請求超時期限（Microsoft SQL Server，錯誤：1222）

如果您只想截斷並重新載入數據，那麼使用索引並不一定有用。

如果您按聚集索引順序（即按CONCEPT_CD ASC順序）插入數據，那麼刪除聚集索引並沒有真正的優勢。最後在 30 億行上重建它比首先在聚集索引順序中插入數據要痛苦得多。

但是，如果要禁用索引，則如下所示：

-- Disable indexes on OBSERVATION_FACT
-- If you're dropping, don't disable. If you're disabling, don't drop...
ALTER INDEX ALL ON OBS_FACT DISABLE;

-- Truncate your table    
TRUNCATE TABLE dbo.OBS_FACT;

-- ETL Process here....

-- REBUILD indexes on OBSERVATION_FACT
-- Or recreate them if you've dropped them in step 1
ALTER INDEX ALL ON OBS_FACT REBUILD WITH (ONLINE = ON);

通過根據腳本立即重建索引來創建後續是沒有意義的，因為創建會建構索引。為什麼要立即重建？

引用自：https://dba.stackexchange.com/questions/99147