SQL更好的性能：char（10）和trim或varchar（10）

我有一個使用代碼的數據庫。每個代碼可以是從兩個字符到十個字符長的任何地方。SQL更好的性能：char（10）和trim或varchar（10）

在MS SQL Server中，使用char(10)代替這些代碼和RTRIM是否更好？或者我應該使用varchar(10)而不必擔心修剪多餘的空格？我需要擺脫空白，因爲代碼將被用於應用程序邏輯進行比較，而不是。

至於平均碼長，很難說清楚。假設所有代碼都是1到10之間的隨機長度。 編輯：對於代碼的平均長度，粗略估計約爲4.7個字符。

來源

2010-04-15 macca1

嘗試運行：'SELECT AVG（LEN（CODE）* 1.0）FROM YourTable' – 2010-04-15 19:05:29

好主意。代碼遍佈許多許多代碼表，但最流行的代碼表的結果是4.74 – macca1 2010-04-15 19:14:02

我會爲varchar投票。

我說varchar避免TRIM會使索引使用失效（除非你使用計算列等等，這會破壞目的，不是嗎？）。

否則，在長度10，這將是50/50，下調提示向VARCHAR的平衡，並通過固定長度的利益

來源

2010-04-15 18:56:43 gbn

爲什麼需要使用TRIM？ – 2010-04-15 19:42:59

因爲這個人正在討論使用char而不是varchar – 2010-04-15 19:45:17

@KM：char列與varchar文字比較會將列轉換爲varchar（數據類型優先級）。然後，你需要修剪它。或CAST文字到字符。無論如何，僅僅使用varchar來簡化代碼就更簡單了 – gbn 2010-04-16 04:49:40

在一個古老的書，我讀了一般char是一個更好的選擇時勝出大部分記錄的實際字符串長度至少爲最大值的60％;在你的例子中 - 如果超過一半的記錄長度爲6或更大。否則，使用varchar。

來源

2010-04-15 19:02:16 a1ex07

我會懷疑這種簡單的陳述，因爲他們會對平臺做出假設。那些東西可能已經被優化，或者在次要版本更新中改變了原因。例如，在Oracle中執行COUNT（1）比COUNT（[star]）快。 Oracle需要多長時間才能使COUNT（[星]）與COUNT（1）一樣快？兩行代碼？所以這樣的東西應該是長期的懷疑。 – 2010-04-15 19:05:15

對不起，在上面的評論我不知道如何逃避星號 – 2010-04-15 19:06:16

您的需求是需要使用varchar的人的教科書定義。

如果你想擔心性能，擔心DB設計和編寫好的SQL。數據庫供應商對Char和VarChar內部進行了很好的優化。

來源

2010-04-15 19:02:40

我相信你無法分辨兩者之間的速度差異。

來源

2010-04-15 19:05:15 codingguy3000

哦，是的，你會的。 10個字節對比1M行上的6.7個平均長度（4.7+長度）給出3個。3Mb消耗的內存空間更少，3.3Mb的讀寫數據少，3.3Mb的日誌寫少，3.3Mb等的備份更小等。 – 2010-04-15 21:12:08

我更喜歡（TimeToComparePerformanceCosts * HourlyRateOfPerson）> =（PerformanceSavings％* HourlyRateOfHardwareCosts） – Nat 2010-04-15 22:31:52

作爲一般規則，總是希望較小的存儲超過額外的CPU。由於數據庫性能的驅動因素始終是IO，較小的數據記錄意味着每頁更多的記錄，這反過來意味着更少的IO請求。處理可變長度所涉及的額外CPU不會是一個因素。歷史上，在80年代甚至90年代的黑暗時代，這可能是一個可衡量的因素，但今天只是噪音。由於CPU和內存訪問量大幅增加，但IO速度幾乎保持不變。這就是爲什麼'舊書'的建議今天不適用。除非你有像char（2）或類似的常量字段，否則只需使用varchar即可。

來源

2010-04-15 20:17:01

SQL更好的性能：char（10）和trim或varchar（10）

回答

相關問題