基於字符的數據的數據庫列大小

Question

我剛剛遇到一個數據庫，其中所有基於字符的列的大小均以8的倍數指定（例如，Username = varchar（32），Forename = nvarchar（128）等）這會影響數據庫的性能嗎？還是完全沒有意義？

謝謝。

N.B.這是在SQL 2000數據庫中。

Answer 1

由於它們是VARchars，所使用的實際空間基於內容。如果他們是CHAR，我會開始擔心。

-Edoode

Answer 2

看起來像我過早的優化。

我不認爲這會使數據庫發生任何性能變化。

Answer 3

這可能只是一些老學校開發者的習慣。正如所說 - varchar只要它需要，所以32或33並不重要，當字符串長度是例如22.

Answer 4

「這是否會影響數據庫的性能或完全是無意義？」

它對性能幾乎沒有影響（不是沒有，但很少）。它可能會對備用空間分配產生影響，因爲使用此方案「最大」行大小可能相當大。每頁幾行可以減慢大表檢索的速度。

但是，與不恰當的索引相比，差異通常是微觀的。

獲得大小「正確」是不值得的時間。在過去的日子裏，老派的DBA每個角色都流汗了。磁盤過去非常昂貴，每個字節都會對成本產生實質性的影響。

現在這個磁盤非常便宜，DBA的時間浪費在大小比磁盤更大的成本上。

Answer 5

如果它們都是5或10的倍數，那麼你會有同樣的擔憂嗎？這是正常情況下發生的情況。

Answer 6

我從來沒有見過它在表格存儲，連接或基本操作上有所不同。

但我已經看到它在涉及字符串處理方面有所作爲。

在SQL Server 2005中，我已經看到varchar大小有顯着差異的唯一情況是，當事情被轉換爲varchar（MAX）或UDF時。這裏似乎有一些差異 - 例如，我有一個系統/進程正在移植一些關鍵列，這些列必須連接在一起形成另一個僞關鍵字段（直到我能夠重構這種可憎的關係）和在中間CTE或嵌套查詢中儘可能快地將結果強制轉換爲varchar（45）。我見過UDF取得和返回一個varchar（MAX）比一個取得和返回varchar（50）表現得差得多的情況，比方說。例如，某人（也許是我！）正在試圖做出未來證明的修剪或填充功能。 varchar（MAX）有它的位置，但根據我的經驗，它可能會對性能造成危險。

我不認爲我分析了varchar（50）和varchar（1000）之間的區別。