我们目前有一个 SQL Server 2000 数据库，其中有一个表包含多个用户的数据。数据以 memberid 为键，该字段为整数。该表在 memberid 上有聚集索引。
该表现在大约有 2 亿行。索引和维护正在成为问题。我们正在讨论将表拆分为每个用户模型一个表。
这意味着我们最终会得到大量的表，如果只考虑正值的话，可能达到 2,147,483,647 个。
我的问题：
有谁有安装包含数百万张表的 SQL Server（2000/2005）的经验吗？
这种架构对于使用查询分析器、企业管理器等进行维护和访问有何影响？
在数据库实例中拥有如此大量的索引意味着什么。
欢迎大家提出意见。
谢谢
编辑：我不同意将这个问题迁移到 Serverfault。这是一个与编程相关的问题。
答案1
以下是一些想法：
1) 不要这么做。说真的。数百万张表格将是一场噩梦，而且可能造成的问题比它解决的问题多得多。
2) 如果您确实想将表拆分成多个表，则不需要使用那么多表。根据您的硬件，我认为 5000 万行没有问题，因此您可以将数据分成 4 个表。
3) 如果可能的话，我会升级到 SQL Server 2005 或 2008 并使用表分区。这样您就可以在表中细分数据。这不是一个完美的解决方案，但比数百万个表要好得多。
为了回答您的具体问题，我想说 SQL Server 不太可能在一个实例中处理那么多表，并且如果每个记录可以有一个表，那么查询分析器等将变得毫无用处。
快速补充：来自微软网站：
数据库对象包括所有表、视图、存储过程、扩展存储过程、触发器、规则、默认值和约束。数据库中所有这些对象的数量总和不能超过 2,147,483,647。
http://msdn.microsoft.com/en-us/library/aa933149(SQL.80).aspx
相当令人惊奇的是，这个数字正是您指定的数字......嗯......
答案2
索引维护应根据现有碎片进行，而不是盲目维护。使用聚集 IDENTITY 列，您不必担心太多。SQL Fool 的碎片整理脚本会有所帮助。
2 亿行数据不算多，也不值得分区，因为查询开销很大，很多表名需要动态 SQL 等。除非你有一个很小的维护窗口，否则
我们每天在一个表中插入大约600万行数据。
根据您提供的信息，痛苦比收获更糟糕。
答案3
拆分成这么多的表简直是一场噩梦，完全不建议这么做。除了其他复杂情况之外，想想添加新用户所需的复杂性——您是否必须动态创建新表？
答案很简单，就是更好的索引，专门针对您使用的查询进行设计。由于您没有详细说明这些查询，我无法给您具体的建议。
但一般来说，我们支持许多具有如此大表的数据库，是的，这可能很麻烦，但绝对是可能的。
如果你做决定在那里实现分区，使用不同的数据划分方式（可能是当前数据与旧数据），以及合理较少的分区数量。请记住，如果您“手动”执行此操作（而不是使用 SQL 2005+ 分区功能），那么针对这些分区表的所有查询都可能需要重新设计。
编辑：针对您问题的一部分，我来具体回答一下，是的，当您有大量表时，企业管理器/查询分析器可能会开始做非常糟糕的事情。我们曾有过设计不佳的数据库，里面有数千个表，您甚至无法展开树视图中的“表”文件夹，除非等待很长时间才能将其全部列出。
答案4
听起来表分区是可行的方法。但是您至少需要 SQL Server 2005。
这是一篇关于该主题的好文章，可以帮助您入门Kimberly Tripp MSDN 文章