更改數據類型時最大化表的可用性
我正在尋找有關將列上的數據類型從 INT 更改為具有 2.2 億行的表上的 BIGINT 的最佳方法的一些建議，因為它已達到 INT 數據類型的上限。
該數據庫位於 SQL Azure DB 上，並且有一個帶有主鍵約束、外鍵約束和非聚集索引的聚集索引。外鍵來自的表也有 3 個包含鍵的非聚集索引。
實現這一目標的最快/最有效的方法是什麼？理想情況下，以最小化表格無法訪問的時間長度的方式。
我計劃通過刪除約束和索引，進行更改並重新創建它們，以及將數據移動到新表中並在那裡創建適當的約束和索引來進行測試，但我想知道是否有人可以提供一些首先對此提出建議。我在網上看到過一些想法，例如批量移動數據，但我不確定哪種方法效果最好。該表本身只有大約 12GB，但我在數據庫的本地副本上測試了整個操作，它生成了 150GB 的日誌。
僅供參考，以防其他人遇到此問題。我最終所做的在上面提到的 Aaron 的系列文章中有所介紹，特別是在第 4 部分：https ://sqlperformance.com/2016/08/sql-indexes/widening-identity-column-4
我沒有走完整的路線來創建視圖和触發器來連接舊表和新表以控制寫入，而是停止通過應用程序寫入表，創建 2 個新表並將現有表中的所有數據選擇到這些表中在添加適當的約束和創建索引、刪除原始表並重命名新表之前，然後更新引用被更改列的儲存過程中的數據類型。在具有 1000 個 DTU 的 Azure DB 性能層上，整個過程只用了不到 25 分鐘。
您沒有說此列是否是任何 FKEY 或索引的一部分。假設不是，實現這一點的最簡單方法是添加一個新的 bigint 列並更新那裡的數據，然後準備一個腳本以將更改應用到其他受影響的對象。潛在地，這些更改可以在一個事務中完成，並且停機時間幾乎為零。