带有额外数据库服务器的庞大数据库[关闭]答案

【问题标题】：Huge database with additional DB server [closed]带有额外数据库服务器的庞大数据库[关闭]
【发布时间】：2013-12-20 16:41:54
【问题描述】：

我们有一个包含数百万条记录的大型 MS-SQL 数据库。有 Java 服务与 DB 交互以进行数据检索。该应用程序处理大量 LIKE、IN 和 JOIN 子句。这会导致更高的 CPU 使用率和更长的 Java 服务调用期间的响应时间。

根据我们的分析，我们在 DB 中确定了 4 个占用大量空间的大表。决定是在不同的服务器中再添加一个数据库并分配足够的内存。然后将这 4 个巨大的表从现有数据库中移到一个单独的表中。

谁能建议这个想法有助于数据库优化，充分利用两个数据库或任何其他有用的技术？

【问题讨论】：

【解决方案1】：

现有服务器的 CPU 是否已用尽？很多时候 CPU 不是问题，而是 I/O 容量（网络、磁盘）。您或许可以在现有服务器上提供更多 I/O 资源，然后将临时数据库、tx 日志以及可能的四个表分布在不同的磁盘上。

将架构拆分到两台服务器对 Java 客户端来说是不透明的。此外，如果这些表和架构的其余部分之间存在参照完整性约束，那么除非您删除约束，否则您将无法执行此操作。

另一种方法是使用事务复制将您的完整架构复制到另一台服务器。您可以将两个实例都放在负载均衡器后面。或者您将所有只读进程移至复制。

不过，复制也有其自身的缺点。例如。架构更改变得更加困难，因为并非所有类型的更改都可以复制。卡住的 tx 复制很难解决。

在开始之前，请确保您有适当的索引。视图 sys.dm_db_missing_index_details 可以帮助您。查看MSDN article 了解如何查询视图。

【讨论】：

嗨@Ralf 感谢您的建议！我们请来了一位来自微软的专家，他提取了所有慢查询，并建议我们将所有 LIKE 替换为等于。我们讨论的其他选项是将特定于应用程序的查询移动到存储过程。你觉得会有帮助吗？
如果您可以接受结果的潜在变化，那么将 LIKE 运算符更改为“=”当然是有益的。这样，您将从索引中获得更好的里程数。你仍然应该检查你是否有所有相关的索引。存储过程...很难说。我想说，如果您 a）选择比最终结果更多的数据，并且您的客户在开展业务之前将其压缩或 b）您的客户计算结果并立即写回，您可以从存储过程中获利到数据库而不进一步使用它自己。