MySQL：多个表还是多个数据库？

对于一个项目，我们有一堆数据，它们总是具有相同的结构，并且没有链接在一起。 保存数据有两种方法：

• 为每个池创建一个新数据库（大约15-25个表）
• 在一个数据库中创建所有表，并按表名区分池

对于MySQL，哪一个更容易、更快地处理

编辑：我对数据库设计问题不感兴趣，我只对两种可能性中哪一种更快感兴趣

编辑2:我会尽量让它更清楚。如前所述，我们将有数据，其中一些数据很少属于不同的池。将一种类型的所有数据放在一个表中并将其与池id链接不是一个好主意：

• 备份/删除一个特定的池是很困难的（而且我们希望在一段时间后主键会用完（即使使用大int时也是如此））

因此，我们的想法是为每个池创建一个数据库，或者在一个数据库中创建许多表。对数据库的50%查询将是简单的

插入

。49%是在主键上进行一些简单的

选择

问题是，
MySQL
处理什么更快？多个表或多个数据库？
为什么不创建一个表来跟踪您的池（列中有PoolID和PoolName，以及任何您想要跟踪的内容）然后在您的15-25个表上，您将在所有表上添加一列，该列将作为一个外键返回到您的池表，以便您知道该特定记录属于哪个池

如果您不想这样混合数据，我建议创建多个数据库。为相同的功能创建多个表会让我的spider感到刺痛。
如果您不希望像TheTXI建议的那样使用一组具有poolID poolname的表，请使用单独的数据库，而不是多个执行相同操作的表

这样，您就可以将不同池的访问限制为初始的“use database”语句，而不必每次都重新编码您的选择，也不必使用动态sql

这种方法的其他优点是：


轻松备份/恢复
轻松启动/停止数据库实例

缺点是：


多一点管理工作，但不多

我不知道您的应用程序是什么，但在创建一个数据库中的所有表之前，请仔细考虑。那样的话，疯狂就是谎言

编辑：如果性能是你唯一关心的事情，你需要衡量它。选取一组具有代表性的查询并测量它们的性能

编辑2：多表/多数据库模型之间单个查询的性能差异可以忽略不计。如果你有一个数据库，你可以调整它的地狱。如果你有很多数据库，你可以把它们全部调出

我（我们的？——不能代表任何其他人）的观点是，对于经过良好调优的数据库，这三个选项（表中的poolid、多个表、多个数据库）之间的性能几乎没有差异，因此您可以选择短期和长期最简单的选项

对我来说，最好的选择仍然是一个具有poolId的数据库，正如TheTXI所建议的，然后是多个数据库，这取决于您（主要是管理）的需要。如果您需要确切了解两个选项在性能上的差异，我们无法给出答案。您需要设置并测试它

有了多个数据库，就可以很容易地使用硬件来提高性能。
我不太确定我是否完全理解您的场景。是否希望所有池都使用相同的表，但只是通过一个区分键而有所不同？还是希望在一个数据库中有单独的表池，每个表上都有一个后缀来区分这些池

但是，无论哪种方式，您都应该有多个数据库，这主要有两个原因。首先，如果必须更改一个池上的模式，则不会影响其他池

第二，如果负载增加（或出于任何其他原因），您可能希望将池移动到具有新数据库服务器的单独物理机器上

此外，对数据库服务器的安全访问可以被更严格地锁定

所有这些事情仍然可以在不需要单独数据库的情况下完成，但这种分离将使所有这一切变得更容易，并减少必须在头脑中跟踪要操作哪些表的复杂性。
我对mysql不是很了解，但我想我必须给出标准的性能答案--“视情况而定”

一些想法（仅涉及性能/维护，而非数据库设计）：


创建新数据库意味着在文件系统中创建一个或多个单独的文件。如果一个文件的性能需要与其他文件分开，那么这些文件可以放在不同的文件系统上，等等
一个新的数据库可能会以不同的方式处理缓存；例如，一个数据库中的所有表将意味着该数据库的共享缓存，而将表拆分为单独的数据库意味着每个数据库都可以有单独的缓存[显然，所有数据库将共享相同的物理内存进行缓存，但每个数据库可能有一个限制，等等]
与单独的文件相关，这意味着如果其中一个数据集变得比其他数据集更重要，则可以轻松地将其拉到新服务器上
分离数据库的另一个好处是，与使用单个数据库相比，允许您一次一个地部署更新

然而，相比之下，拥有多个数据库意味着服务器可能会使用更多的内存（因为它有多个缓存）。我确信多数据库方法有更多的“缺点”，但我现在是空白

所以我想我会推荐多数据库方法
SELECT * FROM database17.accounts_table;