我已经看过一些关于这个问题的论坛，但他们没有回答我想知道的一件事。我将首先解释我的主题：
我有一个系统，其中多个用户的每个日志都输入到数据库中（例如，用户 1 登录，用户 2 登录，用户 1 进入用户管理，用户 2 更改密码等）。所以我预计每个用户每天有 100 到 200 个条目。现在，我在一个表中执行它并查看它，我只需要使用 UserID 过滤掉。
我的问题是，哪个更有效？我应该使用一个表还是为每个用户创建一个表？
我担心如果我使用单个表，系统可能会在过滤数千个条目时遇到一些困难。我已经阅读了使用多个表和单个表的一些优缺点，尤其是在更新表方面。
我也想知道哪个更省空间？多表还是单表？
只要您在要选择的字段上使用索引，就不会出现任何速度问题（尽管索引写入速度很慢，所以太多是一件坏事）。具有几千个条目的表对于 mySQL（或任何其他数据库引擎）来说毫无意义。
创建数千个表的开销要大得多——假设你想更改用户表中的字段——现在你必须更改数千个表。
我们经常搜索单个记录@work 的表有大约 150,000 行，并且由于我们搜索的字段已编入索引，因此搜索时间只需几分之一秒。
如果您在不使用主键的情况下选择这些记录，请在您用于选择的字段上创建一个索引，如下所示：
CREATE INDEX my_column_name ON my_table(my_column_name);
这是最基本的形式。要了解更多信息，请点击此处
我会选择一张桌子。使用 userId 上的索引，您应该能够轻松扩展到数百万行而几乎没有问题。
每个用户一个表可能更有效，但它通常是糟糕的设计。每个用户一张桌子的问题是很难回答其他类型的问题，比如“昨天谁在用户管理中？” 或“有多少人更改了密码？”
至于使用的存储空间 - 我会说每个用户的表可能会使用更多的空间，但是这两个选项之间的差异应该很小。
我只会选择一张桌子。我当然不想每次将用户添加到系统时都创建一个新表。你每天提到的条目数量真的不是那么多数据。
此外，在表的用户列上创建索引以缩短查询时间。
绝对是一张桌子。为应用程序创建的实体动态创建表无法扩展。此外，您需要使用变量表名称创建查询，这使得调试和维护变得困难。如果您在用于过滤的用户 ID 上有一个索引，那么数据库处理数百万行并不是什么大问题。
任何称职的数据库都可以毫不费力地处理包含所有用户信息的单个表。一张桌子绝对是正确的做法。
如果您使用多个表，则每次新用户注册时都需要创建一个新表。您需要为您查询的每个用户创建一个新的语句对象。这将是一团糟。
我也会去单人桌。当您想为具有不同用户集（多租户）的多个客户提供服务时，您可能想要使用多个表。否则，如果您使用多个表，请查看此重构工具：http ://www.liquibase.org/ 。您可以即时进行架构修改。
我想，如果你使用的是正确的索引，那么单表解决方案可以表现得足够好（并且维护会简单得多）。
单表在 PHP 的 $_POST 和 $_GET 准备语句中带来了效率。我认为，对于中小型平台，单表就可以了。总结，几张桌子对多张桌子是理想的。
但是，多个表也不会造成任何破坏。但是，最好的是在一张桌子上。