長列對性能和磁碟使用有何影響？
在我們目前的項目中，它經常發生，我們需要將列擴展幾個字元。從
varchar(20)到varchar(30)等等。實際上，這真的很重要嗎？這個優化有多好？僅允許 100 或 200 甚至 500 個字元用於普通“輸入”欄位有什麼影響？一封電子郵件只能有 320 個字元，所以可以 - 那裡有一個很好的限制。但是，如果我將它設置為 200，我會得到什麼，因為我不希望電子郵件地址比這更長。
通常我們的表不會超過 100.000 行，最多有 20 或 30 個這樣的列。
我們現在使用 SQL Server 2008，但是了解不同的數據庫如何處理這個問題會很有趣。
如果影響非常低 - 正如我所期望的那樣，這將有助於獲得一些好的論據（用連結支持？）來說服我的 DBA，這種長期偏執狂並不是真正必要的。
如果是的話，我是來學習的:-)
您的問題的具體答案（至少對於 Oracle和可能的其他數據庫）是欄位的長度無關緊要，只有數據的長度。但是，這不應該用作是否將欄位設置為其最大允許長度的決定因素。在最大化欄位大小之前，您應該考慮以下一些其他問題。
格式化 任何基於欄位大小格式化數據的客戶端工具都需要特殊的格式化注意事項。例如，Oracle 的 SQL*Plus 預設顯示 Varchar2 列的最大大小，即使數據只有一個字元長。比較…
create table f1 (a varchar2(4000), b varchar2(4000)); create table f2 (a varchar2(5), b varchar2(5)); insert into f1 values ('a','b'); insert into f2 values ('a','b'); select * from f1; select * from f2;壞數據 欄位長度提供了一種額外的機制來擷取/防止壞數據。界面不應嘗試將 3000 個字元插入 100 個字元的欄位，但如果該欄位被定義為 4000 個字元，它可能會。錯誤不會在數據輸入階段被擷取，但是當另一個應用程序嘗試處理數據並阻塞時，系統可能會遇到麻煩。例如，如果您稍後決定在 Oracle 中索引該欄位，您將超過最大鍵長度（取決於塊大小和連接）。看…
create index i1 on f1(a);記憶體 如果客戶端應用程序使用最大大小分配記憶體，則應用程序分配的記憶體將大大超過所需的記憶體。為了避免這種情況，必須進行特殊考慮。
文件 欄位的大小提供了有關數據的文件的另一個數據點。我們可以呼叫所有表 t1、t2、t3 等以及所有欄位 f1、f2、f3 等，但是通過指定有意義的名稱，我們可以更好地理解數據。例如，如果在美國有客戶的公司的地址表有一個名為 State 的欄位，該欄位由兩個字元組成，我們希望在其中包含兩個字元的州縮寫。另一方面，如果該欄位是一百個字元，我們可能希望完整的州名出現在該欄位中。
儘管如此，為改變做好準備似乎確實是謹慎的。僅僅因為您今天所有的產品名稱都適合 20 個字元並不意味著它們總是可以。不要過分將其設為 1000，但要為合理的擴展留出空間。