我试图找出扩展我的网站的最佳方式，我对mssql如何扩展有疑问。
目前表格的方式：
cache_id - int - 标识符
cache_name - nvchar 256 - 用于与event_id一起查找 cache_event_id - int - 基本上是一种分组方式 cache_creation_date - 日期时间
cache_data - varbinary（MAX） - 数据大小从2k到5k左右
存储的数据是一个字节数组，基本上是我网站上页面的缓存实例（压缩）。
我看到的存储的不同方式是：
1）1个大表，它将包含数千万条记录，并且很容易变成几千兆字节
2）包含上述数据的多个表，意味着每个表将有200万到100万条记录
这个数据将用于显示网页，因此在我眼中，任何超过200毫秒的记录都是不好的（我知道有些人认为1-2秒的页面加载是可以的，但我觉得这很慢，我想尽我所能保持低调。）
所以归结为，什么会减慢SQL服务器的速度？
是表的大小（磁盘空间）
是行数
在什么时候停止使用多个数据库服务器变得经济有效？
如果几乎无法预测这些事情，我会接受这个回复。我不是DBA，我基本上试图设计我的数据库，所以我不必在以后重新设计它包含大量数据。
答案 0 :(得分：3)
So it boils down to, what is it that slows down the SQL server?
Is it the size of the table ( disk space )
Is the the number of rows
At what point does it stop becoming cost effective to use multiple
database servers?
这是一个“经验法则”观点; 数据库的负载（因此在很大程度上是性能）主要是2个问题数据量和事务负载的因素，恕我直言，第二个通常更相关。
关于数据量，可以通过规范化，索引，分区，快速IO系统，适当的缓冲区高速缓存大小等来保存许多千兆字节的数据并获得可接受的访问时间。归一化是在DB设计时考虑的问题，其他在系统调整期间考虑的问题，例如，额外/更少的索引，缓冲区缓存大小。
事务负载主要是代码设计和用户总数的一个因素。代码设计包括正确地获取事务大小等因素（小而快是一般目标，但是像大多数事情一样，它可以把它带到远处，并且事务太小而不能保持完整性或者本身很小以至于增加负载） 。
缩放时，我建议先扩展（更大，更快的服务器）然后输出（多个服务器）。多服务器实例的管理问题很重要，我建议只考虑具有操作系统，网络和DBA技能和流程的网站。
答案 1 :(得分：1)
规范化和索引。
我们无法告诉您，因为您没有告诉您使用的是您正在尝试建模的内容或者您尝试使用它的方式。
100万行并不常见。同样，我们不能在没有上下文的情况下告诉你，只有你可以，但不要，提供。
答案 2 :(得分：1)
唯一可能的答案是设置它，并准备好长时间学习的东西，只有你知道，因为只有你会活在你的领域。在您有一些实践经验可以分享之前，您在此处看到的任何技术建议都将是天真且未充分了解的。
测试每一个猜测，比较结果，看看哪些有效。并继续寻找更多可测试的想法。 （并且不要害怕退出最终没有帮助的变化。这是持续简单化的基本要求。）
并接受您的数据库设计将会发展的事实。它并不像你的评论所暗示的那样令人生畏。更改数据库要比绕过它的软件容易得多。