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

Question

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

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

所以从一个方面来看，如果我走 MySQL 路线，我不必担心病毒蔓延或随机 php 文件被上传并以某种方式执行。我还有一条更简单的途径来获得许可并将数据与记录联系在一起。

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

使用 MySQL blob 字段类型是否会影响性能？我担心选择的解决方案会阻碍网站 future 的发展，而且选择的解决方案不容易维护。

Answer 1

Is there a performance hit with using MySQL blob field type?

不是天生的，但如果有大 BLOB 堵塞了表和内存缓存，那肯定会导致性能下降。

The other obvious route is storing the data in a specific folder structure outside of the webroot. in this case I'd have to come up with a special naming convention for folders/files to keep track of what they reference inside the database.

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

这是一个更好的主意吗？这取决于。只有一个数据存储具有部署简单性的优势，而不必担心给予 Web 用户对任何内容的写入权限。此外，如果可能有多个应用程序副本正在运行(例如主动-主动负载平衡)，那么您需要同步存储，这对于数据库来说要比使用文件系统容易得多。

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

• + super 快
• + 缓存良好
• - 额外的服务器配置:虚拟目录；需要适当的文件扩展名才能返回所需的 Content-Type
• - 额外的服务器配置:需要添加 Content-Disposition: attachment/X-Content-Type-Options header 来阻止 IE 嗅探 HTML 作为反XSS 措施

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

• - 可能很慢
• - 需要大量手动 If-Modified-Since 和 ETag 处理才能正确缓存
• + 可以使用应用程序自己的访问控制方法
• + 轻松从服务脚本中添加正确的 Content-Type 和 Content-Disposition header

这是一种权衡，没有一个全局公认的答案。