我应该使用MySQL blob字段类型吗？

Question

我正在努力决定我是否应该在即将到来的项目中使用MySQL blob字段类型。

我的基本要求是，将有某些数据库记录，可以查看，并有多个文件上传和“附加”到这些记录。查看这些记录可以根据具体情况限制到特定的人。任何类型的文件都可以不受限制地上传。

所以从另一方面来看，如果我走MySQL的路线，我就不必担心病毒悄悄而上，也不用担心随机的php文件被上传并以某种方式执行。我也有一种更容易的方法来授权和保持数据与记录的紧密联系。

另一种显而易见的方法是将数据存储在webroot之外的特定文件夹结构中。在这种情况下，我必须为文件夹/文件制定一个特殊的命名约定，以跟踪它们在数据库中引用的内容。

使用MySQL blob字段类型是否会影响性能？我关心的是选择一个会阻碍网站未来发展的解决方案，以及一个不容易维护的解决方案。

Answer 1

如果您的web服务器将通过web为这些上传的文件提供服务，那么如果将它们存储在文件系统中，性能几乎肯定会更好。然后，web服务器将能够应用Last-Modified和ETag等HTTP缓存提示，这将有助于用户多次访问同一文件的性能。此外，web服务器在提供服务时会自动为文件设置正确的Content-Type。如果您将blobs存储在数据库中，那么当您应该从您的web服务器上免费获得这些特性时，您将最终实现上述特性以及更多特性。

此外，从数据库中提取大型blob数据可能最终成为数据库的性能瓶颈。此外，您的数据库备份可能会更慢，因为他们将备份更多的数据。如果您在开发过程中执行即席查询，那么在select语句的结果集中看到大的blobs将是不方便的。如果你想简单地检查一个上传的文件，这将是不方便的，因为它将笨拙地存储在数据库列中。

我将坚持通常的做法，即将文件存储在文件系统上，并将文件的路径存储在数据库中。

Answer 2

使用MySQL blob字段类型是否会影响性能？

不是固有的，但如果有大的BLOB阻塞了表和内存缓存，这肯定会导致性能下降。

另一种显而易见的方式是将数据存储在webroot之外的特定文件夹结构中。在这种情况下，我必须为文件夹/文件制定一个特殊的命名约定，以跟踪它们在数据库中引用的内容。

是的，这是一种常见的方法。您通常会做一些事情，比如让文件夹以它们所关联的每个表的名称命名，包含仅基于主键的文件名(理想情况下是一个整数；当然不会包含用户提交的任何内容)。

这是个更好的主意吗？那得看情况。只有一个数据存储具有部署简单性的优势，并且不必担心给予web用户对任何东西的写访问权限。此外，如果应用程序可能有多个副本在运行(例如，主动-主动负载平衡)，那么您需要同步存储，这在数据库中比在文件系统中容易得多。

如果您使用的是文件系统而不是blob，那么问题是，您是否通过将别名指向文件夹来让web服务器为其提供服务？

• • is超级fast

• • caches well

• • extra服务器配置:虚拟目录；需要适当的文件扩展名才能返回所需的Content-Type

• • extra服务器配置:作为反measures

的一部分，需要添加Content-Disposition: attachment/HTML头以停止IE对X-Content-Type-Options的嗅探

或者，您是否通过让服务器端脚本输出文件来手动提供文件，就像您必须从MySQL blob提供服务一样？

• • is使用应用程序自己的访问控制slow

• • needs来添加来自服务properly

• • can的正确的Content-Type和Content-Disposition报头，这可能会对缓存methods

• • easy进行大量的If-slow

• • needs- ETag和ETag处理

这是一种权衡，没有一个全球都能接受的答案。

Answer 3

根据我的经验，在MySQL中存储BLOB是可以的，只要您只将该blob存储在一个表中，而将其他字段存储在另一个(连接的)表中。相反，在包含几个标准字段和一个包含100MB数据的blob字段的表的字段中进行搜索会显著降低查询速度。

我不得不为这个问题更改了一个邮件应用程序的数据层，其中电子邮件与内容存储在与发送日期、电子邮件地址等相同的表中。搜索10000封电子邮件需要9秒。现在它采取了它应该采取的措施;-)