與數據庫相關的表設計和性能？

Question

我有一個表在SQL Server 2005中有158列。

保持這麼多列的任何缺點。

我也有保留這些多列，

我怎樣才能提高性能 - 比如使用SP的，指數？

Answer 1

寬桌子沒有什麼固有的錯誤。規範化的主要情況是數據庫大小，大量空列佔用大量空間。

Answer 2

您擁有的列越多，查詢就會越慢。

這只是一個事實。這並不是說你沒有理由擁有許多專欄。上面的內容並沒有給我們一個單一的理由，把一個實體的表格與許多列拆分成多個表格，列數更少。這種解決方案的管理開銷很可能超過任何感知的性能收益。

根據我對異常寬表（批量導入數據的非規範化架構）的經驗，我建議給你的第一個建議是儘量減少列數。我必須處理大量瘋狂的數據，並將大多數列保留爲VARCHAR（255）。我建議不要這樣。雖然便於開發，但性能會失去控制，特別是在使用Perl時。將列縮小到最小值（例如VARCHAR（18））非常有幫助。

存儲過程只是批量的SQL命令;除了某些類型的存儲過程的常規使用將最終使用緩存查詢計劃（這是性能提升）之外，他們沒有任何直接的速度。

您可以使用索引來加速某些查詢，但這裏沒有硬性規則和快速規則。良好的索引設計完全取決於您正在運行的查詢類型。根據定義，索引會使寫入速度變慢;它們的存在只是爲了讓你的閱讀更快。

Answer 3

在表中有很多列的問題是使用集羣主鍵查找行可能很昂貴。如果可以更改模式，將其分解爲許多標準化表格將是提高效率的最佳途徑。我強烈推薦這門課程。

如果不是，那麼您可能可以使用索引來加快一些SELECT查詢的速度。如果您的查詢僅使用少量列，則在這些列上添加索引可能意味着不需要掃描聚集索引。當然，就存儲空間和INSERT，UPDATE和DELTETE時間而言，索引總是要付出代價的，所以這可能不適合你。

Answer 4

當您通常需要特定行的所有字段時，寬表可以非常高效。您是否追查過您用戶的使用模式？如果他們通常只從多行中拉出一個或兩個字段，那麼您的表現將受到影響。主要問題是您的總行大小達到8k頁的大小。這意味着SQL必須爲每一行（第一頁+溢出頁面）打印兩次磁盤，並且不計算任何索引命中。

在Universal Data Models的傢伙將有一些好的想法重構你的表。 Red Gate的SQL Refactor使分割表更容易。