我们目前有一个SQL Server 2000数据库，其中一个表包含多个用户的数据。 数据是由整数字段的成员id键入的。 该表在memberid上有一个聚集索引。
这个performance在大约有2亿行。 索引和维护正在成为问题。 我们正在辩论将表格分解成每个用户模型的一个表格。
这意味着我们最终会得到大量的表格，可能会达到2,147,483,647，只是考虑到正面的价值。
我的问题：
有没有人有任何SQL Server（2000/2005年）安装数百万表的经验？
这种体系结构在使用查询分析器，企业pipe理器等维护和访问方面有什么意义。
在数据库实例中拥有如此大量的索引会产生什么影响？
所有的意见是赞赏。
谢谢
编辑：我不同意这个问题被迁移到Serverfault。 这是一个编程相关的问题。
这里有一些想法：
1）不要这样做。 认真。 数以百万计的桌子将是一场噩梦，可能会造成比解决问题更多的问题。
2）如果你真的想把表格分成多个表格，你不需要那么多。 根据你的硬件，我预计5000万行是没有问题的，所以你可以把你的数据分成4个表。
3）如果可能，我会做什么，将升级到SQL Server 2005或2008，并使用表分区。 这将允许您在一个表格中细分数据。 不是一个完美的解决scheme，但远远胜过数百万张桌子。
为了回答您的具体问题，我想说，SQL Server不太可能在一个实例中处理多个表，并且如果每个logging有一个表可能会使查询分析器等无用。
快速添加：从微软网站：
数据库对象包括所有表，视图，存储过程，扩展存储过程，触发器，规则，缺省值和约束。 数据库中所有这些对象的总数不能超过2,147,483,647。
http://msdn.microsoft.com/en-us/library/aa933149(SQL.80).aspx
非常神奇，这个号码是你指定的号码…嗯…
索引维护应该根据现有的碎片进行，而不是盲目的。 有了一个集群IDENTITY列，你不应该有太多的担心。 SQL傻瓜的碎片整理脚本将有所帮助。
2亿行是没有那么多，不值得分区恕我直言，因为查询开销，许多表名需要dynamicSQL等，除非你有一个小维护窗口，也许
我们每天有大约600万行插入，FWIW在一个表中。
根据你提供的信息，痛苦比收益更差。
分裂成许多表是一场噩梦，根本不推荐。 除了其他复杂性之外，还可以考虑添加新用户所需的复杂性 – 您是否必须dynamic创build新表？
答案只是更好的索引，专门针对您正在使用的查询devise的。 既然你没有详细说明这些查询，我不能给你具体的build议。
但是，一般来说，我们支持许多数据库，其大小与表一样大，是的，这可能是一种痛苦，但它绝对有可能。
如果你决定在那里实现分区，使用不同的方式来划分数据（可能是当前的数据与旧的数据），以及相当less的分区。 请记住，如果您“手动”（而不是使用SQL 2005+分区function），则对这些分区表的所有查询都可能必须重新devise。
编辑：在你的问题的一部分的具体答案，是企业pipe理器/查询分析器可以开始做非常糟糕的事情，当你有大量的表。 我们devise的数据库devise不佳，有数千个表，甚至不能在树视图中展开“Tables”文件夹而不用等待所有的时间。
每个用户一个似乎有点像矫枉过正和粗糙的代码库。 您或多或less必须在使用这些表的存储过程中使用dynamicSQL，这绝对会使您的生活和未来的开发和testing复杂化。 （我从经验讲，我们曾经有一些我们每天生成的非常复杂的表;与这些表的所有交互都是dynamicSQL。）
不知道使用这些数据的应用程序的要求，你可以将旧数据变成一个档案或历史表/表？
对于SQL 2k5 / 2k8，您可以使用分区表，这可能也有帮助，并从查询和应用程序中抽象出多个表。 有分区表的一些陷阱，但他们可能在这里工作。
有了这样的数量，你将不得不做一些特定的原型和基准，因为没有一个通用的答案。
听起来像表分区是要走的路。 但是至less需要SQL Server 2005。
这里是一个很好的文章，让你开始Kimberly Tripp MSDN文章
我会重新审视这个devise。
你说它是聚集在成员id，但是这可能会导致页面拆分（和碎片），当数据被添加。 更好地聚集在一个越来越多的代理人身份（并有一个唯一的索引，甚至可能是主要关键，将包括成员id）。
或者，即使不是集群，你也应该在memberid上有一个唯一的索引，剩余的列的唯一部分是唯一的，因为听起来你每个成员有多行。 只有memberid的索引肯定不太可能被覆盖。