我最近继承了一个环境，其中有大约 4000 多个数据库，分布在 3 个大型物理服务器上的 21 个实例之间。数据库根据名称分布在不同的实例之间，因此有些实例比其他实例大几倍。所有数据库的模式都是相同的，但数据不是。一些数据库只有几 MB，而另一些则是 400+GB。
管理层正在考虑我们是否应该尝试在每个实例上保留尽可能多的数据库并减少大型实例。另一个想法是继续向现有环境添加小实例，甚至减少每个现有实例中的数据库数量并增加实例数量。
在管理方面，拥有更少的大实例可能比拥有许多小实例更容易。另一方面，如果大实例发生问题，那么它上面的所有数据库都会受到影响，因此拥有许多小实例可能更安全。
从性能的角度来看，什么会更好？我还应该考虑哪些其他因素？我应该在每个实例上保留多少个数据库？我知道这取决于，但你有一些粗略的估计吗？例如，一个实例上的 500 个数据库是否太多？如果您需要更多信息，请告诉我。
我忘了说所有这些数据库都是不同客户的生产数据库，所以它们都同样重要。开发、测试等在不同的服务器上。
单个 SQL Server 实例知道如何以最佳方式管理其内存、CPU 和 IO。两个（或更多）SQL Server 实例无法协作来协调共享资源的使用。因此，单个实例比多个实例的性能更高。如果您拆分为 2 个（或更多）实例，则需要在它们之间划分资源（理想情况下通过虚拟化），这样实例就不会开始互相踩踏。
举一个具体的例子，考虑一个查询内存授权。这是对缓冲池的保留。多个查询可以启动执行，只要它们的总授权不超过允许的内存。内存授权不会立即分配，因此 BP 不会被驱逐，而是增量使用，并且通常不会使用所有预留（预留是针对最坏情况计算的）。在许多实例上，单个实例可以达到其总内存授予和队列查询的上限，尽管整个系统有能力运行更多。在单个实例上，必须达到总能力，这样租户才能更好地承受峰值。
实例合并的最大缺点和危险是嘈杂的邻居综合症。如果一个租户不断地从公共池中获取更多资源，则会给其他租户带来糟糕的体验，因为他们的工作负载可能会缺乏所需的资源，并且系统对每个人来说都显得很慢。在单个实例上，您将使用资源调控器来控制租户之间的公平性，但控制并不完整。使用虚拟化进行隔离可以提供更好的控制。在同一个物理操作系统上使用多个实例并不理想，恕我直言，它提供的控制比单实例资源治理更差，并且没有提供接近虚拟化提供的隔离的任何地方。我的意见。
因此，我的建议是：要么在 VM 级别拆分，要么合并到单个实例（显然是每个物理服务器）。此外，请考虑使用 Azure SQL DB，具体取决于某些因素，它可能更适合您的方案。
这不是一个完整/明确的答案，而是详细解释我为什么喜欢@Remus 的答案，特别是 VM 推荐，这对于评论来说太长了，而且我对上述答案的支持也没有以任何方式传达。
我在一家环境非常相似的公司工作：Federated Farm 方法在 18 台生产服务器（每个较低环境的节点少得多，但仍然有多个节点）上使用单个数据模型，每个服务器一个实例。唯一的区别是数据（以及服务器/实例名称；-）。我相信它们甚至以 3 组为一组以实现高可用性。这从 SQL Server 2000 开始，一直持续到我们多年后升级到 SQL Server 2005。我们还有一个单独的、单一的实例“控制器”节点，该节点具有不同的数据模型，用于保存公共数据（例如登录、SQL Server 代理 MSX 节点等）以及复制到 18 个联合服务器的静态/查找数据。
这工作得很好，但是当我们准备升级到 SQL Server 2012 时，同时推动了虚拟化，部分原因是新的许可模型（再见，Per Slot 先生；你好先生。有多少核心包我需要再次？）。考虑到我们的高多核服务器，升级成本将非常昂贵。但是——这可能需要支付软件保障——我们可以为核心包支付一次（无论服务器有多少核心），然后在这些服务器上设置任意数量的虚拟机，每个虚拟机共享完全许可的服务器. 我假设我们还必须为我们在许多物理服务器上执行此操作的 VMWare 付费。但我们最终拥有了许多虚拟机，每个虚拟机都有一个默认实例。
这种设置不是我的主意，事实上我对迁移到 VM 并没有抱太大希望，因为我一直读到 SQL Server 应该在物理服务器上（这是很久以前的 2012 年； -)。但是，似乎 SQL Server 已“认证”可以在特定版本的 VMWare 上运行。而且，几年后回顾，结果证明这是一个很好的举措。我们甚至能够摆脱集群，因为他们能够设置 VMWare 以启动新的 VM 并从快照恢复操作系统和 SQL Server 安装，如果任何 VM 崩溃（数据和日志文件都在 SAN-附卷）。
每个实例没有任何硬数据库限制。
当一个实例中有很多数据库时，两件事很快就会用完；max worker threads 和 Agent 子系统，但两者都很容易增加。发生的另一个限制是当一个数据库发疯并开始从缓冲池中搅动其他数据库的页面时。
单独实例的最大原因是：
隔离需要实例级选项或具有猖獗安全要求的麻烦应用程序。
当您测试或从一个版本或配置升级到另一个时。
当您绝望但需要单独修补实例时；尽管有共享和不知道实例的组件以及操作系统补丁，这使得跨服务器而不是实例仍然可以更好地完成这项工作。
除了我一开始介绍的内容之外，您在打包数据库时遇到的问题：
在具有许多数据库的实例中分离性能问题变得极其困难。在同一台服务器上跨多个实例执行此操作几乎是不可能的。
当您的备份计划由一项迭代服务器上数百个数据库的作业触发时，控制或预测备份计划并不难。在数百个实例中做同样的事情要困难得多。几乎不可能阻止它们重叠或公平地安排它们。
您必须非常小心地管理每个实例的最大服务器内存和 CPU 亲和性。然后，您将无法轻松地将其与资源管理器集成，这会剥夺您最简单的管理选项。
出于您的目的，并考虑到这些负担，我会为每台服务器整合一个主要实例（更不用说拥有一个开发环境）。这很有意义。
只要给定实例的 CPU、磁盘和 I/O 级别没有达到最大值，您就处于安全区域。不定期访问的静态内容不会影响 SQL Server 的正常性能。
每个实例都有安全性和合规性检查以保护数据库服务，并且每台服务器都需要定期的软件补丁。此外，将数据库按类别 {开发、测试、生产} 分组到单独的实例上以防止开发人员访问实时数据也是一种最佳业务实践。
根据给定组织的优先级，这个问题有许多不同的正确答案。
以下是有关企业级数据库安全建议的信息
信息保障支持环境 - 安全技术实施指南 (STIG)