目前，我正在開發一款使用MS SQL Server 2005進行相當密集計算的產品。在高層次上，我的產品架構基於「運行」概念，每次我執行一些分析時，它都會存儲在一系列的運行表（每運行約100個表）。將有多個文件組幫助加快我的數據庫？
我遇到的問題是，幾個月後運行次數增加到大約1,000次左右時，數據庫上的性能似乎會下降，特別是簡單的查詢，如檢查表的存在或創建視圖可能需要一秒到兩秒。
我聽說使用多個文件組，我目前沒有這樣做，可以幫助。這是真的，如果是這樣，爲什麼/如何幫助？此外，如果還有其他建議，即使是其他建議，使用較少的表格，我也會向他們開放。我只是想加快數據庫的速度，並希望將其擴大到可擴展的狀態。
在性能方面，使用單獨的文件/文件組的巨大好處是它可以讓你的數據分佈在多個物理磁盤上。這是有益的，因爲使用多個磁盤，可以同時處理多個數據請求（並行通常比串行更快）。所有其他的事情都是平等的，這會使性能受益，但是多少取決於你的特定數據集和你正在運行的查詢。
從您的描述來看，您關心的緩慢操作是創建表格並檢查表格的存在。如果每次運行生成100個表，那麼在1000次運行後，您有100,000個表。我沒有太多經驗在單個數據庫中創建多個表，但是您可能會按下跟蹤數據庫模式的系統表的限制。在這種情況下，通過將表分佈到多個數據庫（這些數據庫仍可以全部位於同一個SQL Server實例中），可能會看到一些好處。
通常，SQL Profiler工具是查找緩慢查詢的最佳起點。有數據列表明每個SQL批處理的CPU和IO成本，這應該指向最差的違規者。一旦找到問題查詢，我將使用查詢分析器爲這些查詢中的每一個生成查詢計劃，並查看是否可以分辨是什麼讓他們變得很慢。通過打開查詢窗口，輸入查詢並按Ctrl + L來完成此操作。對可能很慢的完整討論會填滿整本書，但要查找的好東西是表掃描（對於大表非常緩慢）和低效連接。最後，您可以簡單地通過重寫查詢來改進事情，或者您可能必須對錶格模式進行更廣泛的更改。例如，也許有辦法每次運行只創建一個或幾個表格，而不是1000個。有關您的特定設置的更多細節將幫助我們給出更詳細的答案。
我還建議本網站大量提示，就如何使事情更快：
如果你把它們放在不同的驅動器上 - 不是邏輯的，而是物理驅動器，所以IO不會讓你失望太多。
文件組位於不同的物理驅動器上會帶來最大的性能提升，也可以拆分索引所在的位置，以便表寫入和索引訪問達到不同的磁盤。在分區方面你可以做很多事情，但總體概念是最大速度影響的來源。
它可以幫助提高性能。將某些表格/元素移動到不同的文件區域/磁盤部分。這可以在一定程度上減少影響數據庫的外部碎片量。
我還會考慮一些其他因素，例如tracesql，以確定查詢等爲什麼會變慢 - 還有其他因素，例如查詢統計信息，SP重新編譯等，這些因素更容易修復，並且可以爲您帶來更大的性能提升。
約1000個什麼？單行寫入？多行交易？刪除？
一般的技巧是將數據文件和日誌文件放在單獨的物理驅動器上。 SQL Server會跟蹤每次寫入日誌，因此讓不同驅動器中的這些日誌可以爲您提供更好的性能。
但是SQL Server調整依賴於應用程序實際在做什麼。有一些一般的提示，但你必須測量自己的東西... ...
當你每次運行說說100桌，實際上，你的意思是你要創建新的SQL表？如果是這樣，我認爲你的應用程序的架構可能是問題。我無法想象一種情況，您需要這麼多的新表格，而不是多次重複使用相同的表格，只需添加一列或兩列來區分運行。
如果您已經重複使用同一組表並且新的表格只是表格中的其他行，那麼問題可能只是新數據隨着時間的推移而損害了性能。例如：
＃2是我在現實世界中最經常看到的罪魁禍首。開發人員傾向於開發僅使用一小部分測試數據，並忽略適當的索引，因爲您可以使用20行的表執行幾乎任何操作，並且看起來很快。
希望這有助於
拆分到不同的物理驅動器的表。如果你有那麼多的磁盤IO，你需要一個體面的IO解決方案。 Raid 10，快速磁盤，將日誌和數據塊分成獨立的驅動器。
重新檢查您的架構 - 您可以使用多個數據庫嗎？如果您一次創建1000張表格，您很快就會遇到一些我以前不必處理的有趣瓶頸。多個數據庫應該解決這個問題。想想有一個包含所有主要元數據的「控制」數據庫，然後是包含實際數據的衛星數據庫。
你沒有提及你的服務器的任何規格 - 但是當我們從8GB到20GB RAM時，我們看到了性能的不斷提升。