爲最大速度選擇SQL Server數據類型

我正在設計一個數據庫，需要針對最大速度進行優化。爲最大速度選擇SQL Server數據類型

所有的數據庫數據都是從我稱之爲輸入數據庫（包含我正在編輯的數據，主要是一些折線，標記等等）的輸入數據庫中生成的。因此，數據庫不需要進行編輯，但需要保存儘可能多的數據，以便快速向用戶顯示結果（跨城鎮的路線，自定義多段線等）。

問題是：選擇較小的數據類型，例如int類型的smallint會提高性能，否則會影響它？空間不是一個問題，經過一些快速計算，數據庫不會超過200MB，並且不會有超過100.000行的表（平均值將在5.000左右）。

我在問這個，因爲我在網上閱讀了一些文章，有人說較小的數據類型可以提高性能，其他人則認爲它會影響它，因爲必須完成額外的處理。我知道，對於較小的數據庫，可能結果不明顯，但我對每一點都感興趣，因爲我期待着許多請求，這將觸發更多的查詢。

主機環境將是Windows Server 2008 R2與SQL Server 2008 R2。

編輯1：只給你一個例子，因爲我沒有正確的表結構尚未：我將有一個表將舉行公交線路（200左右的地方），通過鑑定在現實生活中一個獨一無二的數字，並將在各種表格中被引用，並且將在其上進行各種操作。這些引用表將保存最大量的數據。

由於線有獨特的數字，我已經想到了設計的3個例子：

的PK是數據類型的行號：SMALLINT
的PK是數據類型的行數： int
PK有些不同（例如標識），行號存儲在不同的字段中。僅僅爲了爭論，因爲我在'輸入數據庫'上使用了這個不受優化限制的PK，它是一個GUID（16字節）。如果你喜歡，你可以理解這是怎麼壞的比別人比較，如果真的是

所以，請記住，在PK時將在至少15個表，其中一些被引用將會有超過50,000行（其餘的平均值爲5.000，正如我上面所說的），這些行將受到不斷的查詢和操縱，並且我對每一點速度都感興趣。

如果需要，我可以詳細說明這一點。由於

編輯2：而與此相關的另一個問題來到我的腦海，想融入這個討論：

我會看到任何性能改進在這種特定情況下如果我使用原生SQL查詢從我的.NET應用程序內部而不是使用LINQ to SQL？我知道LINQ經過強化優化，能夠在性能方面產生非常好的查詢，但仍然值得一提。再次感謝。

來源

2012-04-22 Tiborg

** YES！**選擇正確的數據類型是在你的設計是至關重要的。較小的數據類型等於較少的字節需要被洗牌 - 所以這一定可以幫助！另外，對於所有字符串列使用'VARCHAR（MAX）'的情況非常不利 - 這些「max」數據類型的處理方式與「常規」Varchar（n）列的處理方式不同（對性能有負面影響，太） – 2012-04-22 10:16:43

關於PK - 讀[GUID的初級和聚集鍵（http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx ）和[磁盤空間很便宜...這不是重點！]（http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx）由金伯利Tripp。使用GUID作爲集羣密鑰是一個**非常糟糕的主意 - 它會導致非常糟糕的索引碎片，從而降低插入，更新，刪除和選擇的速度。 – 2012-04-22 13:26:32

@marc_s感謝這篇文章，我會花更多時間閱讀關於聚集索引的內容，因爲我不太清楚它們是什麼以及它們的行爲。無論如何，我直覺說GUID對於PK來說是個不錯的主意，但現在我知道它爲什麼以及它有多糟糕。但是smallint vs int呢？在低級編程方面，我完全無知，但有人說盡管smallint需要更少的存儲空間，但需要額外的處理來消耗時間。 – Tiborg 2012-04-22 13:46:42

您能指出一些文章說小數據類型=更多處理嗎？請記住，即使使用固態硬盤，當今大多數工作負載都是I/O限制（或內存限制），而不受CPU限制。

特別是在許多表格中要引用PK的情況下，使用可能的最小數據類型將是有益的。在這種情況下，如果這是一個SMALLINT那麼這就是我會用（儘管你說有大約200個值，所以理論上你可以使用TINYINT這是尺寸的一半，並支持0-255）。如果你不能100％確定總會有〜200個值，那麼你需要謹慎行事。一旦你需要256你將不得不改變所有受影響的表中的數據類型，這將是一個痛苦。所以有時候在適應未來增長和擠壓當今絕對的最佳表現之間做出權衡。如果你不確定你永遠不會超過255或32,000的值，那麼我可能只是一個INT。除非你也不知道你將不會超過20億的值，在這種情況下，你會使用BIGINT。

INT/SMALLINT/TINYINT之間的差異在磁盤空間中會比在性能上更明顯。（如果你使用的是Enterprise，磁盤空間和性能的差異可以通過數據壓縮得到很大的抵消 - 特別是當你的INT的值都在SMALLINT/TINYINT之內時，儘管在後一種情況下它確實可以忽略不計，因爲這些值是唯一的）。另一方面，這些和GUID之間的差異在性能和磁盤空間上都會更加明顯。馬克從金佰利那裏得到了一些很好的鏈接; I wrote this article在2003年，儘管它有點過時了，它確實包含了今天仍然相關的大部分重點。

有時需要考慮的另一個折衷（儘管不是在你的具體情況下，似乎）是值是否需要在多個系統中是唯一的。這是您可能需要犧牲某些性能以滿足業務需求的地方。在很多情況下，人們採取簡單的方式，並將自己辭退到GUID。但也有其他解決方案，例如身份範圍，中央自定義序列生成器以及SQL Server 2012中的新對象。I wrote about SEQUENCE早在2010年SQL Server 2012第一個公開測試版發佈時就已經發布。

來源

2012-04-22 13:52:07

與TINYINT的事情是，行號不連續，範圍爲1 - 800。我相信他們不會超過255倍的值，所以我可以使用TINYINT但是這意味着存儲在數單獨的列。當然，在引用表格中，額外的200個smallint值得參考200,000個tinyints，而不是smallint，但我現在能想到的是當我要調試時的痛苦，並確定它會成爲很多。 – Tiborg 2012-04-22 14:11:21

然後我會說堅持'SMALLINT'。正如我上面提到的，在'SMALLINT'和'TINYINT'之間你並沒有真正獲得很大的收益，當它存在時，我寧願堅持使用自然鍵，而不是創建一些任意的替代品。儘管「自然」鍵本身就是另一個系統的替代品。 – 2012-04-22 14:13:09

是的，謝謝你的建議。我想我讀過一些文章，說較小的數據類型=很久以前就有了更多的處理，而且這個想法還在我的腦海裏。我發現他們中的一些人，但他們也很老，他們也提到現在的系統並非如此。 – Tiborg 2012-04-22 14:19:13

我想你將需要提供一些關於表結構和示例查詢的更多細節，這些細節將針對它們運行。根據您提供的信息，我相信選擇較小數據類型的影響只有幾個百分點，我建議您對索引進行更多關注。 SQL Server在通過爲您的查詢和調優顧問工具提供執行計劃來建議創建哪些索引方面做得很好

來源

2012-04-22 10:15:42

我用一個例子更新了這個問題，我認爲應該讓它更清楚一點。 – Tiborg 2012-04-22 13:53:07

-2

我有一個建議是合併一個十進制數據類型，而不是使用字段的組合。例如，我不推薦使用Date（YYYYMMDD），Store（SSSS）和Item（IIII）的表格，而是建議... YYYYMMDD.SSSSIIII。尤其是在使用相同的組合鍵查詢多個表格時，它可以顯着縮短處理時間。

來源

2012-06-07 19:19:24 Ashley

這是可怕的做法 – 2012-10-20 08:24:38

爲最大速度選擇SQL Server數據類型

回答

相關問題