几个较小的一个大型 sql server 表？答案

【问题标题】：one large sql server table of several smaller ones?几个较小的一个大型 sql server 表？
【发布时间】：2014-03-03 08:05:30
【问题描述】：

我有一些设计问题要问。

假设我有一些TBL_SESSIONS 表，我在其中保存每个登录的user-id 和一些Dirty-flag（表明他的内容自从他得到它之后是否发生了变化）。

现在，任何已登录的用户每隔几秒就应该定期向该表询问该Dirty-flag，即该表上有很多读取调用，并且该Dirty-flag 也发生了很大变化.

假设我希望许多用户同时登录。我想知道是否有任何理由创建 10 个这样的表并在这些表之间分配用户（比如根据他们的用户 ID）。

我从两个方面问这个问题。首先，在性能方面。其次，在可扩展性方面。

很想听听你的意见

【问题讨论】：

请定义“llarge”。多少亿行？因为任何低于 1 亿左右的东西都应该是完全没有问题的（除非你认为这是大数据——许多开发人员很遗憾地这样做了）。 25 年前，100 万行很大，今天这很小。
假设有 100 万行（这意味着有 100 万用户登录）
哎呀.. 在回答之前我没有收到您的完整信息。那么，您是说 100 万行的表，每行至少每隔几秒被读取一次，这不是问题吗？
不，一点也不。正确完成时不会，使用某些缓存时不会。
如果没有实际绩效目标，您就无法做出任何与绩效相关的决定，而且您还没有为任何人提供几乎足够的信息来提供经过深思熟虑的回答。阅读记录的可接受持续时间是多少？您期望有多少同时活跃的用户（这会影响缓存数据的机会）？您期望的新记录率是多少？新用户是否可能比老用户更活跃？

标签： sql-server database-design scalability

【解决方案1】：

对于 1m 行，使用单个表。

通过正确的索引，访问时间应该不是问题。如果您使用多个表，用户分布在这些表中，您将需要额外的处理来查找要读取/更新的表。

另外，您将为每个表分配多少用户？当用户数量增加时会发生什么......添加更多表？我认为您最终会遇到维护噩梦。

【讨论】：

在没有更多信息的情况下，这当然应该是默认方法。

【解决方案2】：

如果您有很多记录（例如数十亿条记录）和服务器无法处理的高负载，那么拥有多个表是有意义的。这样您就可以在不同的服务器上执行分片 -> 将一个表拆分为多个。例如。在服务器A（id 1 到 100 000 000）上拥有前 1 亿条记录，在服务器 B 上拥有下一个 1 亿条记录（100 000 001 到 200 000 000）等。其他方式 - 具有 same不同上的数据并通过某种平衡器查询数据，这可能更难（复制不是 RDBMS 的关键特性，因此它取决于引擎）

【讨论】：

在您的示例分片计划中，您将所有新用户负载放在一个分片上。这听起来不是一个好计划。