用於高性能SQL Server數據庫設計的資源

我希望對在線資源（博客，指南等 - 不是論壇）提出一些建議，以幫助我成功設計用大量數據操作的高性能SQL Server數據庫，以及在數據更新和每分鐘查詢方面負載很重。用於高性能SQL Server數據庫設計的資源

對此提出建議？

編輯

我談論的負載主要是在數據營業額方面。主表具有多達一百萬行，大約30個不同大小的數據字段，每天更新大約30-40000個新行，並且每天至少更新200000行新數據。這些更新在一天中持續發生。除此之外，所有更改和更新都需要從數據庫中全天提取，以保持最新的Lucene索引。

來源

2010-03-20 Nathan Ridley

您能給我們一些關於您期望的負載的想法嗎？ – gbn 2010-03-20 15:51:01

聽起來就像一箇中等服務器上相當易於管理的負載 - 您還沒有說過這些插入和更新正在進行時（除Lucene的提取外）發生了什麼樣的讀取操作以及大小（以字節爲單位/ data type-wise）的數據（你給出的基數看起來很好）。

在這一點上，我只想用regular SQL Server best practices推薦 - 確定的模式是合適的（歸一化，則非規範化僅在必要時），review execution plans，使用索引優化嚮導，use the DMVs找到未使用的索引並刪除它們，choose clustered indexes carefully要管理頁面拆分，請謹慎選擇數據類型和大小，並儘可能使用use referential integrity and constraints where possible to give the optimizer as much help。除此之外還有性能計數器，並確保您的硬件/軟件安裝已調整好。

在很多情況下，您絕對不需要超出這個範圍來重新設計架構。

但是，即便如此，如果讀取負載很重，插入和更新可能會導致讀取和寫入之間的鎖定問題，然後您正在爲應用程序查看架構決策。

另外，每天更新一百萬行和200k不會讓我擔心 - 但是你提到了Lucene（即全文索引），所以大概有些列是相當大的。更新大型列並導出它們顯然需要更長的時間 - 以及更多的帶寬和IO。與傳統數據類型列在一個狹窄的百萬行表中的30列將是一個完全不同的故事。您可能需要查看更新配置文件，並查看是否需要垂直分區表以將某些列從行中移出（如果它們較大，則它們將已存儲在行外）以改善鎖定行爲。

因此，當您的讀取負載過重時，關鍵是：插入和更新需要儘可能快，鎖定儘可能少（避免鎖升級），更新儘可能少的索引以支持讀取操作。

如果讀取的負載過重（使插入/更新開始發生衝突），但不需要100％的最新信息（比如5分鐘或15分鐘的延遲不明顯），那麼您可以擁有一個只讀數據庫的維護版本（通過複製完全相同，對性能進行不同索引，非規範化或不同建模 - 如維度模型）。也許你的Lucene索引可以包含額外的信息，這樣昂貴的讀操作全部停留在Lucene中 - 也就是說Lucene覆蓋了許多大的讀操作，從而減少了你對數據庫的讀負載，以支持插入/更新的基本讀取小讀取）和您的應用程序的交易部分（即說客戶服務信息屏幕將使用常規數據庫，而您的小時儀表板將使用輔助數據庫）。

來源

2010-03-21 00:51:18

非常感謝您的詳細回覆 - 將不得不通過這個來消化這一切。 – 2010-03-21 01:15:21