假設儲存在磁碟上，單一資料庫伺服器（無主從架構）的一些粗略效能限制（讀/秒、寫/秒）是多少？根據磁碟類型，每秒有多少讀取、寫入次數？ （SSD 與非 SSD），假設簡單的動作（透過主鍵選擇一行，更新一行，正確索引）。我假設這個限制取決於磁碟尋道/寫入。
編輯：我的問題更多是關於獲取資料庫支援的操作數量的粗略指標：例如，能夠知道是否可以支援觸發 300 次插入/秒的新功能，而無需使用額外的伺服器進行擴展。
答案1
您可以閱讀許多基準測試結果這裡就好像該網站是可靠的來源。
答案2
我可以大膽地建議您對其進行測試以獲得您自己查詢的答案嗎？如果你有 Windows 運行SSIO.exe在您的開發盒上對磁碟進行效能測試，以了解其不執行任何操作的效能。
然後運行效能監視器（假設您在MS-SQL TKProf 中，可能在Oracle 上- 不要使用mysql 或其他工具，抱歉會有類似的工具。）運行您的查詢並查看有多少讀取/寫入以及需要多少CPU來執行它。然後，您可以比較 SSIO 和效能監視器數量，並根據您目前的裝置調整硬體需求，以處理此更新所需的使用者數量/頻率。
話雖如此，對於任何合理的 SQL Server，即使在相當慢的磁碟上，300 行也是一個非常小的行數。除非有大量的複合索引或 blob 等。
答案3
你不能無需對您的應用程式和負載進行基準測試即可進行判斷。
它歸結為RAID 等級、主軸速度、事務大小（不僅僅是「插入」）、觸發器、外鍵、超線程、伺服器上的其他應用程式、伺服器中的RAM、磁碟的排列方式（tempdb 的單獨卷、一個每個 DB t-log、MDF 等）、服務包等級、RAID 控制器快取配置、CPU Ls + L3 快取、核心數量、架構設計、程式碼...
縱向擴展比橫向擴展更容易：如果聯合伺服器或分區表，則會增加開銷。添加 RAM 和更多主軸更便宜。
一篇好文章是Paul Nielson 的 35k TPS。負載至少比您的 300 倍高出 100 倍左右。