我们为地产公司devise网站。 网站只用于显示信息，所有的网站共享一个共同的模板。 我们有大约150个网站为不同的客户。 一些第三方数据提供商每小时向我们提供关于网站上每个列表的更新。 每个客户的更新发生在不同的时间。 平均而言，我们每个网站有1000个列表。 每小时更新80％的数据被更改或更新。
现在我们在Sql server 2008中有一个单一的数据库，用于所有的客户（最初devise为迎合10-20个网站）。 数据库中的表格被所有人共享。 问题是每当更新发生时，它也会减慢其他客户网站的速度，这些网站与更新无关。 同时删除一个客户数据，减慢所有的网站。
我打算通过为每个客户创build一个单独的模式来重新构build数据库，但我不确定是否是处理我们的问题的最佳方法。 有一个单独的数据库会产生很多维护问题（备份，镜像等）。 任何人都可以build议我一个更好的方法来处理这个问题。 我不确定它是如何影响性能的，如果我为每个客户创build一个单独的模式，并将他们的表格分隔开来。 还是有更好的解决scheme？
我个人喜欢多个数据库，因为它允许您查看哪些数据库使用最多的IO和RAM，以及各种DMV – 它允许您轻松地将最大的数据库迁移到其他地方。 此外，还有一个安全分离，总是让客户放心。
布伦特·奥扎尔（Brent Ozar）在最近的一篇博客文章中提到了这个问题 – 绝对值得一读，因为他很好： http ://www.brentozar.com/archive/2011/06/06/how-design-multiclient-databases/
虽然我可能会build议去为每个客户的数据库，如果你想坚持一个数据库，然后看起来像模式将适合您的要求。
但是，除了每个客户的模式外，我还build议您为每个客户创build一个文件组，然后将每个客户的所有数据库对象放入该文件组。 这有几个好处：
我相信你能拥有的最大文件组数量是32,000个，所以这个策略应该持续到你真的需要考虑分裂成不同的数据库。
有关更多信息，我build议在线文章“ 文件和文件组体系结构 ”和有关部分数据库可用性的SQLCAT白皮书： http ://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/partial-database- availability.aspx
如果所有的客户共享相同的数据库，并且所有的网站使用相同的模板，这更像是一个多租户CMS，因此具有单个数据库实际上在这里是非常有意义的。
我不认为这个问题是影响所有其他客户的一个客户更新，而是一般的简单更新和查询的较低水平。 假设硬件和负载不会改变，那么150个数据库可能与单个数据库解决scheme类似（在某些情况下可能较慢）
我假设你的主要表格是拥有大约150 * 1000个活动行（大概+历史logging）的“列表”表。
这不是一个长时间的大量的数据，而一个合理devise的机器应该没有问题。
我会考虑确保历史logging被移到自己的表格中。 在阅读查询，我会添加“读取未提交的快照”
在更新上，有一些可能的修复方法1.使用合并而不是多个更新语句2.使用游标来防止locking3.为更新后的列表添加新logging，只更新“is current”位国旗在旧的
鉴于这是2年前，最终的解决scheme是什么？
这听起来像你更关心的是把所有东西放在一个数据库中，尽pipe你把它放在一个数据库中（尽pipe你把它放在了一个数据库中），因为彼得分解数据库的主要观点与性能有关，并且能够长期扩展。 如果是这种情况，那么您希望将表格拆分为不同的客户模式，或切换到企业版许可证，以便您可以使用表格分区和根据客户编号对共享表格进行分区。
当我计划重组我的数据库基础架构时，我问自己同样的问题。 这篇文章非常帮助我。
[ https://msdn.microsoft.com/en-us/library/aa479086.aspx%5D%5B1%5D