将图像直接存储在数据库中，还是作为base64数据存储？

Question

在数据库中存储图像的常用方法是在存储数据之前将图像转换为base64数据。这一过程将使尺寸增加33%。或者，可以将图像直接存储为BLOB；例如：

$image = new Imagick("image.jpg");
$data = $image->getImageBlob();
$data = $mysqli->real_escape_string($data);
$mysqli->query("INSERT INTO images (data) VALUES ('$data')");

，然后用

<img src="data:image/jpeg;base64,' .  base64_encode($data)  . '" />

采用后一种方法，节省了1/3的存储空间。为什么将图像作为base64存储在MySQL数据库中更常见？

更新：在数据库中存储图像的优点和缺点有很多争论，大多数人认为这不是一种实用的方法。无论如何，我假设我们将图像存储在数据库中，并讨论了这样做的最佳方法。

Answer 1

• Pro base64:您处理的编码表示是相当安全的字符串。它既不包含控制字符，也不包含引号。后一点有助于防止SQL注入尝试。我不期望任何问题只是将值添加到“手工编码”的SQL查询字符串。
• Pro BLOB:数据库管理软件知道它需要什么样的数据。它可以对此进行优化。如果您将base64存储在文本字段中，它可能会尝试为它构建一些索引或其他数据结构，这对于“真实”文本数据来说确实是非常好的和有用的，但是没有意义，而且浪费了图像数据的时间和空间。它是较小的，如字节数，表示。

Answer 2

我认为图像(文件)通常不会存储在base64编码的数据库中。相反，它们以原始二进制形式存储在二进制列、blob列或文件中。

Base64仅用作传输机制，而不是用于存储。例如，可以将base64编码的图像嵌入到XML文档或电子邮件中。

Base64也是流友好的。您可以动态地编码和解码(而不知道数据的总大小)。

虽然base64可以传输，但不存储您的图像base64编码的。

Base64没有为存储提供校验和或任何有价值的东西。

Base64编码比原始二进制格式增加了33%的存储需求。它还增加了必须从持久性存储中读取的数据量，这通常仍然是计算中最大的瓶颈。读取较少的字节并动态对其进行编码通常更快。只有当您的系统是CPU绑定而不是IO绑定，并且您定期输出映像在base64，然后考虑存储在base64。

内联图像(嵌入到HTML中的base64编码图像)本身就是一个瓶颈--您正在通过有线发送33%以上的数据，并按顺序进行( web浏览器必须等待内联图像才能完成下载页面HTML)。

在MySQL和可能类似的数据库中，出于性能原因，您可能希望将非常小的图像以二进制格式存储在BINARY或VARBINARY列中，以便它们与主键位于同一页上，而不是BLOB列，后者总是存储在单独的页面上，有时强制使用临时表。

如果您仍然希望存储base64编码的图像，请确保不将base64编码的数据存储在UTF8列中，然后对其进行索引。

Answer 3

我只想举一个例子，为什么我们决定将图像存储在DB而不是文件或CDN中，它是存储签名的图像。

我们试图通过CDN、云存储、文件来实现这一点，并最终决定将其存储在DB中，并对该决定感到高兴，因为在随后的事件中，当我们移动、升级脚本和迁移站点服务器时，我们证明了这是正确的。

就我的情况而言，我们希望签名包含属于文档作者的记录。

以文件格式存储有丢失或意外删除的风险。

我们将其存储为MySQL中的blob二进制格式，然后以based64编码的图像形式存储在文本字段中。之所以决定更改为based64，是因为由于某种原因导致了较小的大小，并且加载速度更快。由于某种原因，Blob减缓了页面的加载速度。

在我们的例子中，这种将签名图像存储在DB中(无论是blob还是based64)的解决方案是由以下驱动的：

1. 大多数签名图像都很小。
2. 我们不需要索引存储在DB中的签名图像。
3. 索引在主键上完成。
4. 我们可能不得不移动或切换服务器，将物理图像文件移动到不同的服务器，可能导致由于链接更改而找不到的图像。
5. 要求作者重新签名是很尴尬的.
6. 与将其作为文件公开相比，它更安全地保存在DB中，如果安全性受到损害，文件可以下载。存储在DB允许我们更好地控制它的访问。
7. 任何未来的迁移，更改的网页设计，托管，服务器，我们对协调签名文件名和物理文件没有任何担心，这都是在DB！

交流