已经有几个关于这个问题的问题，但我想得到一个更新的答案，因为现在大多数答案都已经过时了。在存储图像、数据库或文件系统方面哪个会更好？
我认为Facebook正在使用数据库，因为图像可以采用各种扩展名：|请参阅此链接，例如： jpeg jpg png gif
虽然看起来是这样，但这不是品味问题，而是性能问题。我已经尝试了两种方式，对于现在活跃的项目，并在开发期间吸取了教训。
将文件存储在数据库中似乎是创建易于部署、维护等的多合一设置的好方法。但是当涉及到较大的文件（例如高分辨率图像）时，它可能会显着增加您的加载时间。
另一方面，说到较小的图像，如用户头像、产品缩略图、其他缩略图，它可以通过减少对服务器文件系统的请求来提高加载速度。在这种特定情况下，这完全取决于您可能拥有的 SQL 技能和查询的优化级别。
我会给你一个建议，我现在已经在涉及许多图像的项目中使用了这个建议，而不仅仅是那些。
在数据库中创建一个表，其结构大致如下：
id INT(5) AUTO_INCREMENT PRIMARY KEY
filename VARCHAR(255)
fullsize_path CHAR(255)
image BLOB
mime CHAR(25)
size INT(20)
错误......你明白了，BLOB字段是你的图像要去的地方。如果它是某些内容的缩略图，则fullsize_path不会留空并提及全尺寸图像的路径。
这样，例如，当显示包含产品的页面时，所有查询都将基于 SQL，但是当访问特定产品时，fullsize_path会告诉浏览器在哪里可以找到老大哥。
当然，在部署这样的东西时，你有更多的事情需要担心，我将在这里概述一些：
- SQL 服务器性能
- SQL 托管图像的最大大小（以字节为单位）
- 要存储的图像量
当然，之前做一些性能测试是一种宝贵的实践！
我建议将文件存储在您网站上的图像/文件夹中或类似的东西中，我会用随机数或 id 保存它们的名称，然后将该信息存储在数据库中。这将是两者的一个很好的组合！
我以前做过使用这两种存储方式的系统，这通常取决于上下文。
对于访问大量服务器数量较少的文件（通常为 1 台服务器）的系统，存储在文件中更易于开发和维护。
对于服务器数量较多的系统，所有服务器都需要访问这些文件。 有时我会使用文件和 rsync 进行设置。 有时我将文件存储在数据库中，让复制处理它。
Facebook或其他网站将其图像存储在数据库中的原因很可能是因为这个原因。 他们需要在很多服务器中访问文件，而无需复制文件的开销。
在数据库中存储图像比在文件系统中存储数据要安全得多。但在性能方面，将图像存储在文件系统中要高效得多。我们必须根据自己的要求选择最好的方式。
您可能还想查看"文件表"选项。 优点是更简单的编程模型（可以使用T-SQL和Windows API）和更简单的管理（通过SSMS），缺点是这使数据库更大。 如果选择此选项，则需要将文件表放在专用文件组上，并且需要调整备份策略以包括文件组备份。
另一种可能性是查看RBS（远程BLOB存储），它作为SQL Server 2012功能包的一部分提供（不在主要产品中）。