這個問題是涉及到另一個問題:
Will having multiple filegroups help speed up my database?在MS SQL Server中管理大量表的最佳方式是什麼?
我們正在開發的軟件是使用MS SQL Server 2005的存儲關係數據分析工具。初始分析可能很慢(因爲我們正在處理數百萬或數十億行數據),但是對於快速回憶以前的分析有性能要求,所以我們「保存」每個分析的結果。
我們目前的做法是保存分析結果在一系列的「運行特定的」表和分析是複雜的,以至於我們可能最終每分析多達100桌。通常這些表每次分析使用幾百MB(與我們的數百GB或有時多TB的源數據相比,這些表很小)。但總的來說,磁盤空間對我們來說不是問題。每組表格都專門用於一個分析,在許多情況下,這就爲我們回溯源數據提供了巨大的性能改進。
一旦我們積累了足夠的已保存分析結果 - 在我們添加更強大的歸檔/清理功能之前,我們的測試數據庫爬到了幾個表中,該方法開始崩潰。但即使在生產中,擁有超過10萬張桌子也不算什麼。微軟在系統對象的規模(〜20億)方面提出了相當大的理論限制,但是一旦我們的數據庫增長超過10萬,那麼像CREATE TABLE和DROP TABLE這樣的簡單查詢就會顯着減慢。
我們有一些空間來辯論我們的方法,但我認爲這可能很難做到沒有更多的上下文,所以我想更普遍地提出這個問題:如果我們被迫創建這麼多的表,什麼是最好的方法來管理它們?多個文件組?多個模式/所有者?多個數據庫?
另注:我不是激動不已的「簡單的問題拋硬件」(即添加RAM,CPU電源,硬盤速度)的想法。但是我們也不會排除它,特別是如果(例如)有人可以明確地告訴我們添加RAM或使用多個文件組將對管理大型系統目錄有什麼影響。
WOW。對於許多表,Management Studio在加載列表時會做什麼?這一定是痛苦的。 – 2008-09-23 23:38:19