我正在为即将推出的网络应用程序进行数据库设计，如果这种设计对于80,000个用户的网络应用程序有效，那么我很想在当前的网络应用程序中大量使用mysql。
1 DB
在数据库中，数百万个表用于每个用户的功能，并且在每个表中，可能有数百万行。虽然这个设计很有活力并且很好地扩展，但我想知道两件事。
感谢任何帮助。
答案 0 :(得分：16)
1 - 绝对不是。几乎所有你问的人都会告诉你数以百万计的表是一个糟糕的主意。
2 - 数以百万计的ROWS很常见，所以很好。
3 - 可能非常糟糕，尤其是如果查询是由认为可以拥有数百万个表的人编写的。这告诉我这是一个不太了解数据库的人。
4 - 见＃3
5 - 无法分辨。您将从额外的表中获得大量额外开销，因为它们都需要额外的元数据。所需空间将取决于索引以及表格的宽度以及许多其他因素。
简而言之，这是一个非常非常糟糕的主意，你不应该这样做。
答案 1 :(得分：4)
数百万行完全正常使用，如果经过适当优化和索引，可以快速响应。
数以百万计的表格表明您已经在如何构建应用程序方面做了大事。数百万行乘以数百万个表，80,000个用户意味着什么，80万亿记录？我强烈怀疑你有那么多数据。
答案 2 :(得分：3)
在表中拥有数百万行是完全正常的，只要您使用适当的索引，MySQL就可以轻松处理这些行。
另一方面，拥有数百万张桌子似乎是一个糟糕的设计。
答案 3 :(得分：1)
除了其他人所说的，不要忘记根据给定的表名找到合适的表也需要时间。多少时间？嗯，这是DBMS内部的，可能没有记录，但可能比你想象的要多。
因此，搜索行的查询可以采用：
（2）可能会更快。
此外，在查询中经常使用不同的表名会降低查询准备效率。
答案 4 :(得分：1)
如果您正在考虑拥有数百万个表，我无法想象您实际上是在设计数百万个逻辑上不同的表。相反，我强烈怀疑你是根据数据动态创建表。也就是说，您正在考虑为每个用户ID创建一个新的TABLE，而不是为用户ID创建一个FIELD，并为每个用户存储一个或多个记录。然后，您将拥有成千上万的表，这些表中的字段完全相同。如果这就是你要做的事：不要。停止。
表应表示您要为其存储数据的逻辑TYPE。您可以创建一个城市表，然后为每个城市创建一条记录。城市表中的一个字段可能表示该城市所在的国家/地区。请勿为每个国家/地区的所有城市创建单独的表格。法国和德国都是“国家”的例子，应该在同一张桌子上。它们不是不同的东西，法国东西和德国东西。
这是要问的关键问题：我想在每条记录中保留哪些数据？如果您有1,000个表都具有完全相同的列，那么几乎可以肯定这应该是一个具有1,000个可能值的字段的表。如果你真的非常认真地保留关于法国的信息而不是关于德国的信息，就像法国一样，你想要一份有首都和人口的省份列表，但对于德国，你想要一份有行业和董事会主席的公司名单，那么好吧，那应该是两个不同的表。但在那时，差异可能不是法国对德国而是其他东西。
答案 5 :(得分：0)
1]查找数据库设计中的维度和事实表。您可以从http://en.wikipedia.org/wiki/Database_model#Dimensional_model开始。
2]注意索引太多：对于高写/更新，你不想索引太多，因为它变得非常昂贵（想想平均情况或平衡b树的最坏情况）。对于高读表，仅索引您搜索的字段。例如在
中select * from mutable where A ='' and B='';
您可能想要索引A和B
3]可能没有必要开始考虑复制。但既然你在谈论10 ^ 6个条目和表格，也许你应该这样做。
所以，我没有告诉你数百万桌问题（并且我的答案是否定的），我认为一点研究会更好地为你服务。至于数百万条记录，它暗示你需要开始考虑“向外扩展” - 而不是“扩大规模”。
答案 6 :(得分：-5)
SQL Server有许多方法可以支持大型表。您可以通过在多个分区（文件组）之间拆分索引，在自己的文件组中放置大表以及在另一组文件组上放置大表的索引来找到一些帮助。
文件组基本上是一个单独的驱动器。每个驱动器都有自己专用的读写头。驱动器越多，一次搜索索引的头越多，因此查找记录的结果就越快。
这是一个详细讨论文件组的页面。
http://cm-bloggers.blogspot.com/2009/04/table-and-index-partitioning-in-sql.html