MySQL 数据库设计 - 存储图像 - 单表或多表答案

【问题标题】：MySQL Database design - Storing Images - Single table or multiple tablesMySQL 数据库设计 - 存储图像 - 单表或多表
【发布时间】：2017-02-02 02:17:49
【问题描述】：

我目前正在开发一种产品，其中包含不同类型的图像，例如产品图像、用户个人资料图片、徽标等。我需要一个具有良好查询性能的数据库。

我想到了两个数据库设计。

选项 1. - 将所有图像存储在具有 id、title、url_full、url_thumb、状态和时间戳字段的单个表中

优势

我可以使用单个 ImageModel 文件插入删除/更新数据。所以图像存储不会有多重逻辑。它只是一个单一的逻辑，“存储在一个表中”。所以每当需要保存图像时，我都可以调用 ImageModel 的方法

缺点

如果产品图片多而用户图片少，由于产品数量庞大，用户图片查询会变慢。

选项 2. - 使用 id、title、url_full、url_thumb、status 和时间戳字段将不同类型的图像存储在不同的表中

优势

增加一个section的记录数不会影响其他section的查询速度

缺点

必须为每种图像类型编写单独的模型文件/函数。
无论何时必须存储图像，都需要指定类型。

我的问题是，哪种方法更好。优点和缺点是否真正值得关注。如果还有其他优点/缺点，请列出。或者如果有其他的神db设计，请提出。

请根据产品和用户多的实际场景回答。

【问题讨论】：

"良好的查询性能" -- 请向我们展示查询；没有他们，我们无法为您提供帮助。
图片的典型尺寸是多少？如果我们谈论的是千字节，那么一个答案会更好；兆字节然后另一个更好。

标签： mysql performance database-design architecture code-maintainability

【解决方案1】：

这开始是一个很长的评论，所以我决定发布它作为答案。在不同的表中存储不同类型的图像对我来说听起来是个坏主意。一方面，如果以后出现新的类别类型，那么该设计将如何扩展？然后你能应付添加任意数量的新图像表吗？此外，查询所有图像需要一系列连接或联合，这可能会很昂贵。

您提到了多图像表架构的以下优势：

增加一个section的记录数不会影响其他section的查询速度

如果您使用在type 列上具有索引的单个图像表，则增加一种类型的记录数不一定会增加对第二种类型图像的查询。这是您提供的单个图像表的缺点：

如果产品图片多而用户图片少，由于产品数量庞大，用户图片查询会变慢。

确实，添加更多记录通常会减慢查询速度。但是，在类型上有一个适当的索引应该会大大减少这个问题。

具有适当索引的单个图像表似乎要好得多。

【讨论】：

谢谢。实际上，我对团队中其他架构师的建议感到困惑。希望这可能是最好的结构
将图像存储在单独的表格中的一种情况可能是有意义的，如果表格太大，例如数百万条记录或更多。但即便如此，您也只是对单表模型进行分片。
我们的应用程序面向 200 万用户......最初将有大约 75000 种产品，随着时间的推移可能会扩大规模......
75K 产品根本不会吓到我，750K 也不会。如果您进入数百万并且性能下降，那么也许是时候重新考虑一下了。
你知道每10000条记录查询速度下降多少百分比吗？也是指数下降吗？？

【解决方案2】：

您将如何提供图片？如果是通过<img src=http:...>，那么只有一个答案：单独的文件。

是的，缩略图可以通过其他机制完成，例如转换为 base64 并包含在 img 标记中。如果页面上有很多缩略图，这可能是最好的。

但是，将缩略图与您查询的列放在同一个表中可能不利于性能。所以我们需要查看查询和表模式（目前为止）。

【讨论】：