假设存储在磁盘上，单个数据库服务器（无主从架构）的性能限制（每秒读取、每秒写入）大致是多少？根据磁盘类型，每秒读取和写入的次数是多少？（SSD vs 非 SSD），假设操作简单（按主键选择一行，更新一行，正确索引）。我假设此限制取决于磁盘寻道/写入。
编辑：我的问题更多的是关于获取数据库支持的操作数量的粗略指标：例如，能够知道是否可以支持触发 300 次插入/秒的新功能，而无需通过添加其他服务器进行扩展。
答案1
您可以阅读许多基准测试结果这里好像该网站是一个可靠的来源。
答案2
我可以大胆地建议你测试一下，以获得你自己问题的答案。如果你有 windows 运行SSIO 工具在您的开发箱上对磁盘进行性能测试，以了解它在不执行任何操作的情况下的运行情况。
然后运行性能监视器（假设您使用的是 MS-SQL TKProf，可能在 Oracle 上 - 不要使用 mysql 或其他，抱歉会有类似的工具。）运行查询并查看执行此操作需要多少次读取/写入以及需要多少 CPU。然后，您可以比较 SSIO 和性能监视器数字，并根据您当前的设备调整硬件要求以处理此更新所需的用户数量/频率。
话虽如此，对于任何合理的 SQL Server 来说，即使在相当慢的磁盘上，300 行都是非常少的需要更改的行数。除非有大量复合索引或 blob 等。我有一个实时进程，用户观察一个查询，该查询创建了 1.5M 行，在相对普通的硬件上运行只需几分之一秒。
答案3
你不能无需对您的应用和负载进行基准测试即可进行判断。
它归结为 RAID 级别、主轴速度、事务大小（不仅仅是“插入”）、触发器、外键、超线程、服务器上的其他应用程序、服务器上的 RAM、磁盘的排列方式（tempdb 的单独卷、每个 DB t-log、MDF 等一个）、服务包级别、RAID 控制器缓存配置、CPU Ls + L3 缓存、核心数、模式设计、代码......
向上扩展比向外扩展更容易：如果联合服务器或分区表，则会增加开销。添加 RAM 和更多主轴更便宜。
一篇好文章Paul Nielson 的 35k TPS。至少比你的300左右高100倍的负载。