这取决于你要存储的图像数量和它们的大小。我曾经使用数据库存储图像，我的经验是相当不错的。

在我看来，使用数据库存储图像的优点是，

A.你不需要FS结构来保存你的图像 B.当存储更多的项时，数据库索引比FS树执行得更好 C.智能调优的数据库在缓存查询结果方面表现良好 D.备份很简单。如果您设置了复制，并且内容从用户附近的服务器传递，那么它也可以很好地工作。在这种情况下，不需要显式同步。

如果你的图像很小(比如< 64k)，并且你的db的存储引擎支持内联(记录中)blob，它可以进一步提高性能，因为不需要间接(实现了引用的局部性)。

当您处理少量大尺寸图像时，存储图像可能是一个坏主意。在db中存储图像的另一个问题是，像创建、修改日期这样的元数据必须由应用程序处理。

有一件事我还没有看到任何人提到，但绝对值得注意的是，在大多数文件系统中也存在与存储大量图像相关的问题。例如，如果您采用上面提到的方法，以主键命名每个图像文件，在大多数文件系统上，如果您试图将所有图像放在一个大目录中，一旦您达到了非常大的图像数量(例如数十万或数百万)，您将遇到问题。

常见的解决方案是将它们散列到平衡的子目录树中。

不经常编辑的小静态图像(不超过几兆)应该存储在数据库中。这种方法有几个好处，包括更容易移植(图像与数据库一起传输)，更容易备份/恢复(图像与数据库一起备份)和更好的可伸缩性(一个包含数千个小缩略图文件的文件系统文件夹对我来说听起来像是可伸缩性的噩梦)。

从数据库提供图像很简单，只需实现一个http处理程序，将从DB服务器返回的字节数组作为二进制流提供服务。

我会选择两种解决方案，我的意思是……我将开发一个小组件(EJB)，它将映像存储在DB中，并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时，这个DB才会更新。然后，我还将该路径存储在业务DB中。

从应用程序的角度来看，我将始终使用文件系统(从业务DB检索路径)，通过这种方式，我们将修复备份问题，并避免可能的性能问题。

唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜，拜托!

我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。

这里有几个问题:

database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem

我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的，在工作流结束时被删除。如果有任何形式的长期存储，我们肯定会选择存储文件路径。

还应该注意的是，我们在内部使用客户端/服务器应用程序，因此不需要担心web界面。