为什么要为高流量/容量表使用单独的数据库？

Question

在查看我正在使用的应用程序的数据库结构时，我认识到它在同一 SQL Server 实例上使用 3 个不同的数据库来处理不同的事情。

第一个包含很少更改的主要数据。

第二个包含高流量和容量的事件日志，最后一个是旧事件日志的存档数据库。

我想知道这种结构的好处是什么，因为数据库运行在同一个实例上，数据库文件位于同一个磁盘上。因此，我不希望由此带来任何性能改进。

我想，也许我忽略了一些东西，有人可以指出我没有想到的好处。

更新：
在维护和安全方面提出了一些好的观点。但我仍然想知道是否有可能获得性能改进。

一个更普遍的问题是：一个表的性能是否会受到同一数据库中其他大表的影响（由于碎片或其他原因），或者这些影响可能可以忽略不计。

Answer 1

你在这里有两个不同的问题，我将分别回答。

Q：同一个数据库中，一张表的性能会受到其他大表的影响吗？

是的，在插入/更新/删除期间。SQL Server 每个数据库只有一个日志文件。当您插入/更新/删除时，您的事务在您的数据写入日志文件之前不会完成。

假设我们有两个表：

• 文档 - 存储东西的大型 XML 表示。只有两个字段，一个 ID 和一个 XML 字段，但这并不意味着记录很小。当我们插入到这里时，我们需要将整个 XML 写入日志文件，我们的 XML 文档往往是每个 5-10MB。
• 订单 - 存储来自我们网站的传入订单。这是一个小表 - 没有 XML 或 VARCHAR(MAX) 字段，只有一些客户和产品的 ID。当我们在这里插入时，它只有 1K。

如果这两个表都在同一个数据库中，并且我们在编写文档时也尝试下订单，则订单事务的性能可能会变慢。

现在，这是一个极端的例子，但通常这就是为什么我建议将关键任务、高价值、小宽度记录表与不太关键、价值较低、大宽度记录表存储在单独的数据库中的原因。但是，如果您需要将两组表恢复到完全相同的时间点，或者在服务器之间一起故障转移，那么它们需要位于同一个数据库中。SQL Server 不保证故障转移时数据库之间的事务一致性，例如 AlwaysOn 可用性组。

Q：如果我有快速变化的数据、缓慢变化的数据和永不变化的数据，我是否应该将它们分开到不同的数据库中？

是的，有几个不同的原因：

• 不同的备份计划 - 我需要确保尽快备份快速变化的数据。通常，人们使用单个备份作业对其所有数据库进行完整备份，并且通常他们不会在进行完整备份的同时进行事务日志备份。如果我有一个 10GB 快速更改的数据库和一个 1TB 永不更改的数据库，并且如果我使用单个完整备份作业，则意味着在我的 1TB 完整备份进行时，我可能无法获得任何事务日志备份。这是潜在数据丢失的更大窗口。您可以通过单独的备份作业或更严格的计划来缓解这种情况。您真正想要做的是避免备份永不改变的数据 - 更少的 IO 负载，更少的备份文件被拖到磁带上。
• 不同的索引重建和统计更新作业 - 我不想在没有变化的大型数据库上进行索引重建/碎片整理。理想情况下，我使用 100% 填充因子重建所有索引，使用全扫描更新统计信息，并将数据库设置为只读。Presto，密集的页面，更快的性能而无需锁定麻烦。（另外，作为一个偏执的 DBA，我可以确保没有人会那样改变它。）
• 不同的 HA/DR 策略 - 如果我有一个很少更改的大型稳定数据库，我可能会将其置于只读模式，然后将该只读副本还原到我的灾难恢复环境中。当我将数据从主数据中心复制到辅助数据中心时，我只需要担心频繁更改的数据。

Answer 2

询问设计该解决方案的开发人员/架构师。只有他们自己才能真正说清楚。我可以想到几个原因：

1. 数据库可能是在不同时间添加的。首先是主数据库，然后他们决定需要一个事件数据库，最后一个存储旧数据的地方。根据环境的不同，创建一个新数据库可能比向现有数据库添加大量新表更容易。我曾经工作过的系统，有时会备份生产数据，将其作为只读存档放在网上，然后从当前数据库中删除所有旧数据 - 从而同时有多个旧数据库可用。

2. 未来的使用：也许他们认为系统最终必须分散在不同的服务器上（或者可能只是用于高流量数据库的更快的光盘）。

3. 计划不同的备份时间等。也许存档永远不会停机备份，但可用于统计（24/7），生产可能每天或更频繁地备份，以及事件日志的其他计划？

它实际上可能是上述全部、部分或全部......