您可以在一台 SQL 伺服器上放置的數據庫數量是否有任何限制？
我正在建立一個 SaaS 系統，我們計劃為每個客戶提供自己的數據庫。該系統已經設置好，因此如果負載變得太大，我們可以輕鬆地擴展到其他伺服器；我們希望有成千上萬的客戶，甚至數以萬計的客戶。
問題
- 您可以/應該在一台 SQL Server 上擁有的微數據庫數量是否有任何實際限制？
- 它會影響伺服器的性能嗎？
- 擁有 10,000 個每個 100 MB 的數據庫，還是一個 1 TB 的數據庫更好？
附加資訊
當我說“微型數據庫”時，我並不是指“微型”；我只是說我們的目標是成千上萬的客戶，所以每個單獨的數據庫只佔總數據儲存的千分之一或更少。實際上，每個數據庫都在 100MB 左右，具體取決於它的使用量。
使用 10,000 個數據庫的主要原因是為了可擴展性。事實上，V1 系統有一個數據庫，當數據庫在負載下緊張時，我們有過一些不舒服的時刻。
它使 CPU、記憶體、I/O 緊張——以上所有。儘管我們解決了這些問題，但它們讓我們意識到，在某些時候，即使擁有世界上最好的索引，如果我們像我們希望的那樣成功，我們根本無法將所有數據放在一個大本營’ 數據庫。所以對於 V2，我們正在分片，所以我們可以在多個數據庫伺服器之間分配負載。
去年我一直在開發這個分片解決方案。它是每台伺服器一個許可證，但無論如何，由於我們在 Azure 上使用虛擬機，因此已經處理好了。現在出現這個問題的原因是因為以前我們只向大型機構提供服務並自己設置每個機構。我們的下一個業務訂單是自助服務模式，任何擁有瀏覽器的人都可以註冊並創建自己的數據庫。他們的數據庫將比大型機構小得多，數量也多得多。
我們嘗試了 Azure SQL 數據庫彈性池。性能非常令人失望，因此我們切換回正常 VM。
我曾在單個實例上使用 8 到 10,000 個數據庫的 SQL Server 工作。這不漂亮。
重新啟動伺服器可能需要一個小時或更長時間。想想 10,000 個數據庫的恢復過程。
您不能使用 SQL Server Management Studio 在對象資源管理器中可靠地定位數據庫。
備份是一場噩夢，因為要使備份有價值，您需要有一個可行的災難恢復解決方案。希望您的團隊擅長編寫一切腳本。
你開始做一些事情，比如用數字命名數據庫，比如
M01022和T9945。試圖確保您在正確的數據庫中工作，例如，M001022而不是M01022，可能會令人抓狂。為這麼多數據庫分配記憶體可能會非常痛苦。SQL Server 最終會執行大量 I/O，這可能會真正拖累性能。考慮一個記錄 10,000 家公司的 4 個表中的碳使用詳細資訊的系統。如果你在一個數據庫中這樣做，你只需要 4 個表；如果您在 10,000 個數據庫中執行此操作，那麼您突然需要在記憶體中儲存 40,000 個表。在記憶體中處理這麼多表的成本是巨大的。如果有 10,000 個數據庫正在使用，則您設計的任何將針對這些表執行的查詢都需要計劃記憶體中的至少10,000 個計劃。
上面的列表只是您在以這種規模執行時需要計劃的問題的一小部分。
您可能會遇到諸如 SQL Server 服務需要很長時間才能啟動的問題，這可能會導致服務控制器錯誤。可以自己增加服務啟動時間，創建如下系統資料庫項：
子項：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 名稱：ServicesPipeTimeout 類型：REG_DWORD data：服務啟動時發生超時前的毫秒數例如，要在服務超時前等待 600 秒（10 分鐘），請鍵入 600000。
自從寫下我的答案後，我意識到問題是在談論 Azure。也許在 Azure SQL 數據庫上執行此操作不是那麼成問題；也許問題更大。就個人而言，我可能會設計一個使用單個數據庫的系統，可能在多個伺服器上垂直分片，但肯定不是每個客戶一個數據庫。