我有两条路线，
1） 为每个用户创建子表并存储其个人内容
2） 创建几个表，并在其中存储所有用户的数据。
例如。
1） 100000个表，每个表有1000行
2） 50个表，每个表有2000000行
我想知道哪条路线最好，效率最高。
上下文：就像Facebook一样，对于数百万用户来说，他们的帖子、照片、标签。所有这些信息都在一些巨大的表中，供所有用户使用，或者每个用户都有自己的子表。
这是MySQL中这两种方法的一些优点和缺点。
1.许多小桌子
缺点：
- 使用更多的并发表意味着需要更多的文件描述符（请检查此项）
- 一个有100000个表的数据库一团糟
优点：
- 小表意味着小索引。小索引可以完全加载在内存中，这意味着您的查询将运行得更快
- 此外，由于索引较小，像插入这样的数据操作将运行得更快
2.很少有大的表格
缺点：
- 巨大的表意味着非常大的索引。如果索引不能完全加载到内存中，那么大多数查询将非常缓慢
优点：
- 数据库（以及您的代码）非常清晰，易于维护
- 如果您的表变得很大，您可以使用分区。（勾选此项）
根据我的经验，一个200万行的表（我处理过7000万行的表格），如果你能够在内存上加载所有活动索引，那么在MySQL下就不会有性能问题。
如果你有很多并发用户，我建议你评估其他技术，比如Elastic Search，它似乎更适合这类场景。
为每个用户创建一个表是最糟糕的设计。这是数据库设计课上教给你的第一件事。
表是数据库的强逻辑组件，因此它用于RDBMS的许多维护任务。例如，通常设置表文件空间、限制、配额、日志空间、事务空间、索引树空间和许多其他内容。如果每个表都有自己的文件来放入数据，那么在连接表或其他任何表时，都会有很大的往返时间。
当您创建许多表时，您将在维护方面有很大的开销。此外，你会否认关系来源的本质。假设您正在将记录添加到数据库中——每次都创建一个新表？这对你的代码来说会有点困难。
但话说回来，你可以试着自己看看。
您应该利用MySQL索引的强大功能，它将基本上提供类似于每个用户一个表的功能。
在user_id上创建一个名为username_data的索引表将（从大的方面来看）转换您的查询，该查询在user_idhere子句，如下所示：
SELECT picture FROM user_data WHERE user_id = INT
进入：
- 在索引中查找user_data中的行，其中user_id=INT
- 然后，在这批行中加载图片的值
通过这样做，MySQL不会搜索user_data中的所有行，而是搜索索引中的相关行。