如何缩放SQL Server 2008（或2012）？从根本上讲，我知道有两种选择：
放大：
如果受CPU限制，我可以清楚地看到从1个CPU内核变为2到4个内核。或者，如果RAM使用量猛增，只需增加更多RAM。假设没有应用程序级别更改，SQL Server 2008/2012是否真的采用了这种方法并按比例扩大规模？为了最大程度地减少猜测，假设我没有做一些愚蠢的事情，例如燃烧CPU周期，进行交叉联接等。
向外扩展：
目前还不清楚横向扩展如何工作。我的意思是，如果我在第一个SQL服务器旁边添加了另一个SQL服务器，该查询如何知道要在哪个服务器上运行？前面是否有一些负载均衡器（SQL Server软件随附它吗？）？是否需要更改应用程序级别才能向外扩展正常工作？还是我必须对数据进行分片，并具有根据数据分片键调用正确的数据库服务器的自定义代码？
希望能有更多有经验的人提供意见。
Answers:
SQL Server不会像这样向外扩展。它扩大了。
有3个区域可以执行此操作，但受版本限制
当然，请使用更高的版本，例如Enterprise
SQL Server不会分片，任何此类解决方案（您都可以研究MySQL分片解决方案）会增加系统的复杂性和开销。
通常，使用RAM，SSD，更多磁盘卷来分发IO，为tempdb和日志使用单独的驱动器等来扩展一台服务器（+备用节点/镜像）通常非常简单。
另外，如果您发现SQL Server受CPU限制，那么除非您的工作量很大，否则通常设计和/或索引和/或编写的查询不佳。
就像gbn所说的那样，SQL并没有像其他RDBM那样真正地向外扩展。但是，向外扩展的一个方面是许多人忽略了这一点，那就是始终有一个单独的系统来进行报告。
切勿让报告针对生产运行。在另一台服务器上构建自己的报告数据库。
理想情况下，您的报告系统将仅包含报告所需的数据，并且在结构和优化方面与生产系统不同。
数据将根据需要输入到报告系统中（例如，每小时从生产，每天的进料等中进行点滴更新）。
一种快速而又肮脏（且效率很低）的方法是简单地在另一台服务器上拥有生产数据库的完整副本。可以通过完整备份，事务日志传送，镜像（带有快照），复制等维护此副本。
但是我不推荐这种方法。完全备份和还原需要时间，尤其是在较大的数据库上。复制是复杂且有问题的。日志传送使您拥有只读数据库。使用快照进行镜像可能是一个很好的答案，但是您仍会陷入生产模式的问题，该模式并未针对报告目的进行优化。
一个单独的报告系统是要走的路。
如果CPU受限，我可以清楚地看到从1个CPU内核变为2个到4个内核。或者，如果RAM使用率猛增，只需增加更多RAM。如果不更改应用程序级别，SQL Server 2008/2012是否真的可以弥补这一不足并进行扩展？
SQL Server的不同版本在要使用的CPU和内存方面有不同的限制。但是除此之外，答案是肯定的-如果有空闲的CPU周期或内存页面可用，则服务器通常会在需要时使用它们，除非另行配置。
还是我必须分片数据并拥有调用正确数据库服务器的自定义代码
基本上是。当您需要避免锁争用时，通常会执行“向外扩展”。如果您的查询长期运行且具有广泛的锁定，则可能需要将它们与“实时”交互式查询或由用户操作某种界面并等待迅速响应的查询启动的查询更新周期分开。显然，解决此问题需要更改应用程序（或者，如果您具有3层设计，则至少需要更改中间件）。