一般来说，我认为将图像存储在文件系统中并通过数据库条目链接到它总是更好。但是，我正在尝试优化我的数据库设计并且有几个问题。
我的图像都是非常小的黑白缩略图（不是灰度，而是真正的黑白），尺寸为 70x70。如果我们获取图像（基本上是一个 1 和 0 的二维数组），它可以存储为每个大约 600 字节的二进制数据。
所以我的问题是查询存储在数据库中的 600 个字节是否比查询链接然后访问文件系统更快；假设正在进行大量“图像”查询。
有没有人有这方面的经验？
如果重要的话，我正在使用 MySQL 和 MonetDB（分开，但对两者都有相同的问题）。
非常感谢，布雷特
如果它只有 600 字节，那么我不会太担心并将它们作为 blob 存储在数据库中
High Scalablilty上有一篇关于 Flickr 架构的有趣文章。这可能对您有用。
既然您标记了问题 sql-server，那么我建议您阅读To Blob 或 Not To Blob，遗憾的是 Jim Gray 的研究论文。本文详细介绍了在文件系统 (NTFS) 与数据库 (SQL Server) 中存储BLOB的主题，您会惊讶于考虑了多少角度。这是必读的。但结论是这样的：
研究表明，如果对象平均大于 1 兆字节，NTFS 比 SQL Server 具有明显优势。如果对象小于 256 KB，则数据库具有明显优势。在此范围内，这取决于工作负载的写入密集程度以及系统中典型副本的存储年龄。
您的案例显然属于“To BLOB”案例。
SELECT *据我了解，如果您无缘无故地不使用（坦率地说，根本没有理由使用） ，那么在数据库中存储更大的文件是没有问题的SELECT *。
BLOB 和 TEXT 与其他数据分开存储，如果不明确查询不会影响性能。
如果您在谈论 Web 应用程序，那么将图像存储在数据库中只是愚蠢的。因为您没有桌面应用程序可能获得的好处，而只有困难。
这不仅与文件大小有关，还与数据库工作时您期望拥有的最大记录量有关。过去，我们曾经为任何类型的字段进行这种数学运算。只需乘以 600 字节即可获得最大记录量，如果结果是可管理的，则不必担心速度。
正如@codeholic 所说，如果您不使用 SELECT *，一切都会好起来的。
将图像存储在数据库中（并在每个请求上提供它）可以防止您将这些图像缓存在代理服务器中（或者更确切地说 - 使任务复杂化许多倍并且几乎所有开箱即用的解决方案都被禁止）。问题是，要衡量影响，您需要以不同的方式看待它 - 而不是“单个查询获取图像需要多少时间”问自己“一系列（在此处输入合理的数字）查询需要多少时间获得相同的图像集”。也许还问自己“我必须支付往返数据库的费用吗？”。
并不是说这个想法没有价值 - 在单个位置更新图像可能是一个重要因素。此外，如果高可用性是一个因素，那么将数据库配置为数据中心点要容易得多（将图像放在文件系统上意味着在更新时在节点之间同步它们）。更改跟踪、权限、附加数据、避免“断开的链接”——这些也可能发挥作用。
除了以上所有，我在使用“文件系统”技术时有过糟糕的经历。目前我们正在考虑转向“数据库”技术。