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

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

和大多数问题一样，这并不像听起来那么简单。在某些情况下，将图像存储在数据库中是有意义的。

存储的图像 动态变化，比如发票和你想要的 因为它是在1月1日 2007年? 政府希望你保持6年的历史 存储在数据库中的映像不需要不同的备份策略。存储在文件系统上的映像可以 如果图像在数据库中，则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。这需要一个非常坚定的管理员去窥探数据库提取图像

另一方面也有相关的问题

需要额外的代码来提取 然后播放图像 延迟可能是 比直接文件访问慢 数据库服务器负载过重

我负责一些管理许多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

我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中，并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:

通过更新全局配置，将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具，如imagemagick。 在web应用程序中，您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。

你的网络服务器(我假设你正在使用)是用来处理图像的，而数据库不是。因此，我会大力投反对票。

在数据库中只存储路径(可能还有文件信息)。

没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统，甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?

如果你的文件系统中有你的图像，当你写一个新版本甚至删除文件时，有人正在读取文件-会发生什么?

我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。