我正在爲我的數據庫設計實時AJAX Web應用程序的功能和性能，目前我沒有資源來添加數據庫服務器冗餘或負載平衡。SQL 2008 R2獨立服務器應該存儲在單個表中的最大建議行數是多少？
不幸的是，我在我的數據庫中有一張表，可能最終會存儲數以百萬計的行，並且需要快速讀寫，以防止滯後於Web界面。
本表中大多數（如果不是全部）列都是單獨索引的，我很想知道在大型表上運行查詢時是否還有其他方法可以減輕服務器的負擔。但是，在單個非集羣SQL服務器開始窒息之前，最終是否有表的大小上限（行或 GB）？
我的數據庫只有十幾個表格，可能有幾十個foriegn關鍵關係。我的表格中沒有任何列的列數多於8列，並且只有一個或兩個表格最終會存儲大量的行。希望我的數據庫的簡單性將彌補這些情侶表中海量的數據...
行嚴格受限於可用磁盤空間量。我們有SQL服務器，其中有數億行數據。當然，這些服務器相當大。
爲了保持Web界面的活潑，您需要考慮如何訪問該數據。
一個例子是遠離任何類型的需要處理大量數據的聚合查詢。像SUM（）這樣的東西可能是一個殺手，取決於它試圖處理的數據量。在這些情況下，您最好提前計算任何摘要或分組數據，並讓您的站點查詢這些分析表。
接下來，您需要對數據進行分區。將這些分區分成不同的驅動器陣列。當SQL需要到磁盤時，它可以更容易並行讀取。 （@Simon觸及了這一點）。
基本上，問題歸結爲您需要在任何時候訪問多少數據。無論您在磁盤上擁有多少數據，這都是主要問題。如果驅動器速度較慢，並且DB服務器中可用的RAM數量不足以將DB的內存量保持在內存中，即使小型數據庫也可能會被阻塞。
通常對於像這樣的系統來說，大量的數據基本上是惰性的，這意味着它很少被訪問。例如，採購訂單系統可能會保留所有有史以來創建的發票的歷史記錄，但它們實際上只處理任何活動的發票。
如果您的系統具有類似的要求，那麼您可能有一張用於活動記錄的表格，並將其作爲夜間過程的一部分簡單歸檔到另一個表格中。您甚至可以將統計數據（例如每月平均值）重新計算爲該檔案的一部分。
只是有些想法。
我的服務器只有8GB RAM，但應該是足夠用於基本緩存 - 如果需要，我可以輕鬆升級。不幸的是，大部分數據需要不斷地和一般地訪問，但是歸檔表仍然是一種選擇。我最終可能會創建一個存檔表，並處理這樣一個事實，即在需要歷史數據時，我必須將兩個查詢的結果結合起來。至於分區，我只有一個磁盤陣列 - 五個1TB驅動器帶有1TB奇偶校驗。當你沒有多個數組時，分區仍然有用嗎？ – Giffyguy 2010-12-20 20:02:09
@Giffyguy：如果你不能將它分散到多個物理驅動器上，我沒有看到分區的理由。所有讀頭都不能一次在兩個地方。從頭開始，他們可以......嗯。您可能會詢問關於在同一陣列上對sql進行分區的serverfault後續操作。 – NotMe 2010-12-20 20:54:23
我的直覺告訴我，你可能會好起來的，但你將不得不應對性能。這將取決於可接受的查詢時間來檢索查詢結果。
對於具有「數億行」的表格，定期訪問多少百分比的數據？是否有一些數據很少被訪問？是否有用戶訪問選定的數據，其他用戶選擇不同的數據？您可能受益於數據分區。
唯一的限制是您的主鍵的大小。它是INT還是BIGINT？
SQL將愉快地存儲數據，沒有問題。但是，擁有1億行數據，您可以最好地對數據進行分區。有很多好的文章，比如這個article。
使用分區，您可以讓每個分區同時運行1個線程，以便在沒有分區的情況下進行並行查詢。
INT給你40億行 - 'BIGINT'相當多一點:-) - 對於絕大多數的情況下，我想...... – 2010-12-20 19:23:52
分區似乎是一般性建議，儘管我只有一個磁盤陣列可以使用 - 5個1TB驅動器帶有1TB奇偶校驗。 @mark_s：實際上'INT'給你大約20億，因爲它已經簽名，但是我使用'BITINT' - 無意中切斷可擴展性...... – Giffyguy 2010-12-20 19:57:16
這一切都取決於您的訪問模式。例如，如果您執行表掃描，那麼比僅僅執行索引查找更重要。 – Gabe 2010-12-20 19:17:02
@Gabe：大多數情況下我只是做索引查找，所以這是個好消息... – Giffyguy 2010-12-20 20:04:08