我想将用户的数据拆分到不同的表中，这样就不会有一个包含所有数据的大表。。。
问题是，在与主表不同的表中，我无法识别每个数据属于谁
在注册期间，我是否应该在每个表中存储相同的用户id？它不会产生不必要的重复吗？
编辑：示例
表：
| id | user | email | phone number| password | followers | following | likes | posts |
成为
表1:
| id | user | email | phone number| password |
表2:
| id | followers num | following num | likes num | posts num |
这看起来像一个；XY问题">
你想"没有一张大桌子"；。但是为什么您有这个要求？
可能是因为某些场景中的一些响应比您预期的要慢。
与其像Gordon Linoff提到的那样，以各种方式拆分表(这是一种SQL反模式，可能会让您比以前更陷入困境)，不如监视您的系统，并测量您使用的各种查询的性能，并按频率对其进行加权。也就是说，如果查询#1在每个周期内执行十万次，耗时0.2秒，那么您应该将20000秒记为查询#1。查询#2花费了50倍的时间(整整10秒)，但只运行了100次，它只会累积第一次查询总时间的二十分之一。
(由于最终用户注意到长延迟，因此有些用户使用此公式的变体，将一个查询的实例乘以其持续时间(以毫秒为单位)的平方或更高的幂。这样，较慢的查询会受到更多关注)。
不管怎样，一旦您知道哪些查询应该首先优化，然后您就可以开始优化您的模式了。
首先要检查的是索引。也许还有正常化。这些覆盖了"；低性能"；到目前为止，我遇到过一些案例。
然后是分割。可能不是在你的情况下，但你可能有一个交易表，或者你通常只对当前太阳能或财政年度感兴趣的交易表添加包含该信息的列会使表变大，但只选择那些至少符合年份条件的记录会使大多数查询运行得更快。这在较低级别上也得到支持(参见"Sharding")。
然后是粗心的JOIN和子SELECT。通常，它们开始的时候又小又快，所以没有人愿意检查索引、规范化或条件。几年后，内部SELECT正在收集一百万条记录，而外部JOIN丢弃了其中的九万九千条。翻译子选择中的丢弃条件，并查看查询起飞。
然后你可以检查一些信息是否真的很少被访问(例如，我有一个数据库，每个用户都有一堆财务信息，但这可能只在0.1%的请求中需要。因此，在这种情况下，是的，我将这些信息拆分到了一个辅助表中，也获得了支持在系统中注册了多个银行账户的用户的可能性。请注意，这不是我这样做的原因)。
在这一切中，还要考虑到时间和金钱。进行分析、运行修改并检查，再加上任何停机时间，都会付出一些代价，甚至可能增加维护成本。也许——只是也许——把更少的钱投入到更快的磁盘、更多的RAM或更多或更快的CPU中，可能会实现同样的改进，而无需更改架构或代码库。
我认为您想要使用LEFT JOIN
SELECT t1.[user], t2.[posts]
FROM Table1 AS t1
LEFT JOIN Table2 AS t2 ON t1.id= t2.id
编辑：这里有一个文档链接，解释了不同类型的JOINS
我相信我理解你的问题，如果你想知道，可以使用外键。当你有一个用户列表时，确保每个用户都有一个特定的id。
稍后，当您插入关于用户的数据时，您可以通过会话变量或get请求插入用户id。(插入不同表格)
然后，当您需要从不同的表中提取特定用户的数据时，您只需从表中选择id=session[id]或获取[id]
这有帮助吗？
答案：使用外键来识别用户使用获取和会话的数据
如果要从主表中删除这些值，请不要担心重复。
对于PRIMARY KEY，一个表可能有一个AUTO_INCREMENT；另一个表将具有相同的PK，但它将不是AUTO_INCREMENT。JOINing这些表将把这些表"放回一起"进行查询。
很少有充分的理由对表进行"垂直分区"。一种罕见的情况是拆分"like_count"或"view_count"。这样，主表就不会被计数器的连续UPDATEing所困扰。在某些极端情况下，这可能有助于提高性能。