不，因为页面分割。实际上，您定义的行可以是1KB - n MB，因此数据库的页面中会有大量空白，这对性能不利。

在数据库中只存储映像的文件路径的问题是，不能再强制数据库的完整性。

如果文件路径所指向的实际映像变得不可用，则数据库会不知不觉地出现完整性错误。

考虑到图像是被寻找的实际数据，并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失)，而不必与某种文件系统(如果文件系统是独立访问的，图像可能会突然“消失”)，我倾向于将它们直接存储为BLOB或类似的文件系统。

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

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

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

另一方面也有相关的问题

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

通常，我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库)，并将所有负载都放在其中。另一方面:它极大地简化了备份策略，特别是当你有多个web服务器，需要以某种方式保持数据同步时。

像大多数其他事情一样，这取决于预期的规模和预算。

如果您使用Teradata，那么Teradata Developer Exchange有一篇关于加载和检索lobs和blobs的详细文章。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading