我正在向我的网站添加一些功能，以便用户可以上传自己的个人资料图片，所以我想知道是将它们作为 BLOB 存储在数据库中，还是将它们放在文件系统中。
我在这里发现了一个与此类似的问题：Storing images in DB: Yea or Nay，但给出的答案更适合人们期待成千上万甚至数百万张图像，而我更关心小图像（JPEG 最高可能是 150x150 像素），并且数量很少：可能最多一两千。
对于这种情况，DB BLOB 与文件系统有何感受？客户端如何从数据库缓存图像与从文件系统缓存图像？
如果存储在数据库中的 BLOB 是要走的路 - 我应该知道在哪里存储它们吗？由于我认为我的大多数用户不会上传图片，我是否应该在需要时创建一个user_pics表以（外部）加入常规users表？
编辑：我重新打开这个问题，因为它不是你链接到的那两个的重复。这个问题专门针对少量图像使用 DB 或 FS 的优缺点。正如我上面所说，另一个问题是针对需要存储成千上万张大图像的人。
要回答您的部分问题：
客户端如何从数据库缓存图像与从文件系统缓存图像？
对于数据库：在数据库中有一个 last_modified 字段。使用 Last-Modified HTTP 标头，以便客户端的浏览器可以正确缓存。当浏览器请求图像“如果较新”时，请务必发送适当的响应（不记得它叫什么；一些 HTTP 请求标头）。
对于文件系统：做同样的事情，但文件的修改时间。
如果存储在数据库中的 BLOB 是要走的路 - 我应该知道在哪里存储它们吗？由于我认为我的大多数用户不会上传图片，我是否应该创建一个 user_pics 表以在需要时（外部）加入常规用户表？
我会将 BLOB 和相关元数据放在它自己的表中，并在它与您的用户表之间存在某种关系。这样做会更容易优化数据的表存储方法，使事情更整洁，并为可扩展性留出空间（例如，一般的“文件”表）。
我曾经遇到过一个用于 pdf 文件的小型 DMS 的类似问题。该场景与您的不同：最多可能有 100 个文件，每个文件大小不超过 10 MB - 这不是您对个人资料图片的期望。但是当时朋友给我的答案也适用于您的情况：
将每个存储系统用于其设计用途。
将数据存储在数据库中。将文件存储在文件系统中。
这不是最终的答案（*），但它是初学者的一个很好的经验法则。
正如 Aaron Digulla 在他的回答中所说，我从未听说过 Windows FS 速度慢，有时甚至不可靠。如果有这样的问题，这当然需要考虑。但对于头像图片，我觉得它并不重要。
(*) 我知道，我知道，42...
DB 针对延迟、事务等进行了优化。
图像存储针对读取延迟、存储成本等进行了优化。
Blob 存储非常适合存储数百万张图像。我在 SeaweedFS 上工作。它基于 Facebook 存储用户照片的设计。
从服务他们的角度，编写服务他们的代码，备份程序等，什么会更方便？你想给自己正确的答案，而不是给别人的正确答案。
从我的角度来看，任何可能留在数据库之外的东西都应该留在外面。它可能是您不会每天复制或备份的文件系统或单独的表。它使数据库更轻巧，增长更慢，更易于理解和维护。
如果您使用的是 MSSQL，请确保 blob 存储在单独的数据文件中。不像其他一切一样在初级。
在 Windows 上，尽可能多地放入数据库中。文件系统有点慢，有时甚至不可靠。
在 Linux 上，您有更多选择。在这里，您应该考虑将大文件移动到文件系统中，并将名称保留在数据库中。如果您使用像 Ext3 或 ReiseFS 这样的现代文件系统，您甚至可以创建许多性能相当不错的小文件。
您还需要考虑如何访问数据。如果您拥有数据库中的所有内容，则您有一个访问路径，无需担心另一组权限，但您必须处理读取/写入 BLOB 的额外复杂性。在许多数据库中，无法搜索 BLOB。
在文件系统上，您可以对您的数据运行其他工具，如果文件存储在数据库中，这是不可能的。
我会将它们存储在数据库中：
由于您谈论的是少量图像，因此易用性/管理应该优先于链接问题中争论的性能问题。
我认为将它们存储在数据库中具有可管理性的优势。它们可以与其他数据一致地备份和恢复 - 您不会忘记删除过时的数据（嗯，您可能会，但可能性较小），如果您将数据库迁移到另一台机器，图像会随它。