为Webapp的每个客户端创建一个新表是一个好主意吗？

这是半假设的，由于我没有处理大型数据库表的经验，因此我不知道这是否由于某种原因而令人恐惧。关于情况：

想象一下一个基于Web的应用程序-可以说是会计软件-它具有20,000个客户端，每个客户端在一个表中有1000多个条目。那就是2000万行，我知道这肯定会减慢复杂查询的速度。

在这种情况下，在数据库中为每个客户端创建一个新表是否更有意义？数据库对拥有20k（或更多！）表有何反应？

一般来说，不，每个客户都有一个表（我想您实际上是在这里指数据库）是没有意义的。对于数据库表而言，2,000万行相对较小。只要数据库已正确调整（建立索引）并且查询正确组合在一起，查询速度就不会成为问题。无论您认为将它们分开可以获得什么好处，都将被管理20,000个单独数据库的额外复杂性所抵消。例如，当您想更改表结构时会发生什么？您现在必须做20,000次！

更糟糕的是，如果您最终确实发现数据库的大小成为问题，那么以后总是可以将它们分散到单独的数据库中。

听起来是个坏主意。

不要试图用这种奇特的结构使数据库胜过智能。数据库引擎经过了很多优化，可以处理大型数据集。例如，您所描述的内容听起来非常接近于手动实现索引的尝试。只需使用数据库引擎提供的索引，它们的实现要比您自己可能会做的要好得多，并且不需要太多维护。

另外，作为一般经验法则。我建议不要以在应用程序正常使用期间需要操纵或创建数据库结构（表，字段）的方式来设计数据库。它使性能优化变得不堪重负，并且经常迫使您向用户授予太多权限来执行例行任务，从而可能造成安全漏洞。

当人们提出这个问题时，我总是敦促他们阅读以下文章：

http://datacharmer.blogspot.com/2009/03/normalization-and- smoke.html

恕我直言，单个表应该不是问题，所以不要创建一个不存在的问题-到目前为止。您可以做很多事情来提高性能。您可以基于clientID或日期字段将单个表划分为多个文件，以帮助IO。您的数据库无需跟踪，优化和缓存您网站上需要的每个查询的20,000个不同的sql语句。您可以按clientid编制索引。2万个客户可以为很多硬件付费。

对于这种类型的表，可以使用NoSQL类型的db。

对于2万个客户端，数据库可能不是您最薄弱的环节，那么为什么要引入这么多的复杂性呢？

那真是不好的方法。

垂直分区表，两台数据库服务器一个用于奇数用户ID，另一台用于偶数ID应该工作良好（数据在用户之间不相关）。

按user_id对数据进行排序，如果不可能，则获取大量的RAM或SSD磁盘。