將 char(10) 更改為 varchar(12) 對海量表的影響
我在 Microsoft SQL Server 2005 伺服器的數據庫中有一個表，大小為 16gb，有 5800 萬行。
它有一個名為“balance_forward”的列，它是 char(10)（數字列的不尋常選擇，但我沒有設計表格）我需要增加它的大小以容納大小超過十個字元的餘額（xxxxxxxxx. xx)
我嘗試將其更改為 char(12) （有風險，我不找任何藉口）但我認為*這導致數據庫的日誌文件增長了許多 GB（並填滿了日誌驅動器）並且操作無論如何都失敗了（數據類型仍然字元（10））
後來我意識到至少更改為 varchar(12) 會更有意義，這樣該列不會強行佔用更多空間，但它會有更多空間來容納更大的數據。
我的問題是 - 這也會導致日誌文件再次增長（我設法通過將其他文件移出日誌驅動器來釋放一些空間）
我是否正確地假設使用 varchar 而不是 char 會阻止現有數據佔用更多空間？
（理想情況下，數據類型應更改為最適合財務餘額的類型，但我認為這將是 5800 萬行的更劇烈變化）
*我不能確定。我以為在操作之前我在日誌驅動器上看到了足夠的空間，但我可能看到了“mb”並將其誤認為是“gb”。所以可能是日誌已經填滿了驅動器。顯然日誌可以增長，直到填滿分配的驅動器/空間
基於這個和這篇文章，我會說，是的，從
char(10)to的變化varchar(12)會觸及每一行，因此會增加日誌。我的推理是，列已經從行結構的固定長度部分移動到可變長度部分，儲存引擎將不得不立即保存這些資訊。可變長度列將有兩個字節的成本來跟踪實際長度（見上文）。如果您的數據的平均長度為 8 字節或更少，那麼您將通過這種方式獲得勝利。否則，您將佔用更多空間
varchar。您需要的數字可以以數字類型儲存在 9 個字節中。我懷疑這會對您的應用程序造成太大的改變，即使它是保存這些數據的正確方法。
我建議您添加一個正確類型和長度的新可空列。從上面的文章來看，這將是一個只有元數據的操作，日誌記錄最少。放置觸發器以使新列與現有列保持同步。然後，您的應用程序可以在執行以下步驟時繼續工作。以塊的形式複制現有數據。在您的開發箱上進行測試，以找出適合您系統的已用時間和日誌大小的塊大小。根據我的經驗，10,000 是正確的。一切就緒後，刪除舊列和触發器，然後重命名新列。需要重建索引來回收空間。這是一些處理這個主題的SO文章。