根据某个类别ID，您有什么想法将大型SQL表分成几个？

Question

我们有一个大型表，可以在许多网站上为许多不同的存储过程提供服务，但通常只处理表中与使用它的网站相关的数据。

换句话说，用networkID拆分表是不对的？

Answer 1

如果这意味着您要在多个服务器上安装多个数据库，那么这是推荐的扩展方法之一。如果你指的是同一台服务器上的多个表（相同的数据库或不同的数据库），那么你的收益就会很少;并且您的管理开销可能会增加以保持同步。如果在遇到多个表的所有查询中都存在任何情况，则效率会降低。

无论好坏，效果都不大。你期望什么是好处？ （顺便提一下，这是一个典型的rdbms反模式，用于过早优化。）

Answer 2

是的，这是错的。你应该在websiteid上保留一个表和索引。如果你真的想让它们看起来分开，你可能想要使用分区视图，但我不认为这是必要的。

在SQL术语中，你永远不应该根据它的过长（即行数）来分解表，但你可能会考虑根据过大的宽度（即列数）来分解表。

Answer 3

如果要将应用程序移动到自己的表中以进行隔离，最好每个实例设置一个数据库，而不是尝试在应用程序中执行此操作。这具有以下优点：

• 查询的SQL没有 变化

• 通过以下方式保护数据更容易 数据库比通过表分区。 您可以为客户提供更多 无需灵活访问数据 妥协其他客户的数据。

• 您可以实施独立 备份/恢复机制 必要时以每个客户为基础。

• 通过移动“向外扩展”更容易 一些客户到另一台服务器上 你必须。

• 应用程序架构是 更简单，因为它不必是 明确地了解客户 在每个查询中过滤。

基于每个客户设置多个表意味着您必须为应用程序维护单独的构建，或者生成涉及这些表的所有SQL语句。这很麻烦，难以扩展到大量客户。

作为概括，如果您有一个相对简单的应用程序和大量客户，那么带有过滤的单个表可能是更合适的解决方案。对于客户较少的更复杂的应用程序，最好的方法是设置多个数据库并为每个客户提供一个应用程序实例。

Answer 4

您的意思是您希望拥有BigTableForWebsite1，BigTableForWebsite2，BigTableForWebsite3等，而不是一个BigTableForAllWebsites？这让我在数据库纯粹的胃里感到有点不适......

我认为它不会给你带来性能提升，因为每次访问仍然会对单个数据库起作用（可能存储在一组文件中）。