Mysql SQL效率：多个表或多个行

假设我有一个照片管理数据库，目前有100个用户注册到该数据库，每个用户有10000张照片绑定到他们的用户id。每个用户只能访问他们自己的照片

为每个用户提供100个表（以用户id作为表名）以及各自的10000张照片是不是更有效？或者一个包含所有1000000张照片的表是不是在数据库性能方面没有任何差异

在这两种情况下，数量都将继续增加（即更多用户或更多照片）

---

编辑：我目前正在使用MySQL构建数据库，最初考虑将指向图像的链接存储在单个文件夹中。我想我对如何处理这个问题有了更好的想法！谢谢你的回复

对于多对一关系，您可能只需要两个表。一个包含用户ID（可能还有其他用户信息）的表，一个包含照片和用户ID（外部键控到用户表）的表

大概是这样的： 用户表

UserID  Name  DateJoined  etc.
1       Dan   2015-01-01  ...
2       Jim   2015-02-01  ...

照片表（如果要在SQL Server上使用FILESTREAM，可以将实际照片存储在表中；我不建议在MySQL上使用）

您的ImagePath必须是唯一生成的（使用GUID/UUID作为文件名，将所有用户的照片存储在特定目录中，或者类似于这些内容）

---

如果您真的想存储照片并将其与用户关联，则可能需要考虑NoSQL／文档数据库。 这是MySQL还是SQL Server？您是在数据库中存储图像/二进制数据，还是仅存储用户信息？无论哪种方式，您几乎肯定不希望每个用户都有一个唯一的表。一般来说，您的模式应该是静态的（应用程序代码中没有需要模式更改的更改）。因此，一个包含1m张照片的单表是正确索引的最佳方式，它的性能也比单独的表要好。如果您计划将实际的图像二进制文件存储在一个表中，请不要这样做。如果您计划在数据库中存储照片的引用。。。对于基本的图像信息，将图像保存在一个目录中，并将用户ID保存在磁盘上就足够了——这样，您可以使用文件名来存储一些信息，这样会更高效。当涉及到对图像和元数据进行更高级的操作时，当然最好将引用存储在一个表中。但是，将此大小的表中的字段数量保持在最小值。在这种情况下，OP为什么需要第三个（关联）表？照片都由一个用户拥有，因此第二个表中的

owner

列应该足以创建1:many关系。关联表只适用于许多关系。啊，我错过了每个用户拥有自己照片的部分。你说得对。我会修改这篇文章。如果你想存储的唯一动态信息是标题，我不明白你为什么会想要这样一张大桌子。在文件系统中保存数据（使用用户id作为目录名，使用编码的标题作为文件名）将完成这项工作。请参阅我对问题的评论。因为您可能（也将）希望在该表中存储其他元数据。最后一次访问照片，谁喜欢照片，等等。与文件共享相比，让多个服务器访问SQL中的信息和元数据更容易。我会选择NoSQL，但即使这样，您最终还是需要关系数据（谁喜欢等等），如果您想添加更多元数据，那么为什么不只保存表中的元数据而不保存文件引用？mysql表中的100万行或更多行速度非常慢，非常快-您可能希望将字段数量降至绝对最小，以保持行大小较小。

PhotoID  UserID PhotoPath        PhotoTitle
1        1      '/img/asdf.jpg'  'My favorite'
2        2      '/img/asdf2.jpg' 'First!'
3        1      '/img/asdf3.gif' 'Animated favorite'