为了简单起见，假设我正在开发一个像Instagram这样的移动应用程序。用户可以从服务器下载图像，也可以上传自己的图像。目前，服务器将所有图像（实际上只是小缩略图）作为BLOB存储在MySQL数据库中。似乎最常见的图像传输方式是使用Base64编码，这给我留下了两个选择：
- 服务器将所有图像存储为BLOB。要上传图像，客户端将其编码为Base64字符串，然后将其发送到服务器。服务器将图像BACK解码为二进制格式，并将其作为BLOB存储在数据库中。当客户端请求图像时，服务器将图像重新编码为Base64字符串，并将其发送给客户端，然后客户端将其解码回二进制以供显示
- 服务器将所有图像存储为Base64字符串。为了上传图像，客户端将其编码为Base64字符串并发送到服务器。服务器不进行编码或解码，只是将字符串存储在数据库中。当客户端请求图像时，Base64字符串会返回给客户端，然后客户端对其进行解码以进行显示
显然，选项#1需要在服务器上进行更多的处理，因为每个请求都必须对图像进行编码/解码。这让我倾向于选择#2，但一些研究表明，在MySQL中存储Base64字符串的效率远低于将图像直接存储为BLOB，而且通常不鼓励这样做。
我当然不是第一个遇到这种情况的人，所以有人对实现这一点的最佳方法有建议吗？
JSON假定utf8，因此与图像不兼容，除非它们以某种方式编码。
Base64的体积几乎是二进制（BLOB）的8/6倍。有人可能会说，它很容易负担得起。3000CCD_ 1变为约4000CCD_。
每个都应该能够接受任意的8位代码，但不是每个人都能接受。Base-64可能是不必处理8位数据的最简单和总体上最好的折衷方案。
由于这些都是"小"的，我会将它们存储在表中，而不是文件中。但是，我会将它们存储在一个单独的表中，并在需要时通过适当的id存储JOIN。这允许不需要映像的查询运行得更快，因为它们不会跨过BLOB。
从技术上讲，TEXT CHARACTER SET ascii COLLATE ascii_bin可以，但BLOB更清楚地表明，该列中实际上没有任何可用的文本。
为什么要对连线上的图像进行base64编码？我认为你是从一个错误的假设开始的。
我不明白为什么DB服务器不应该总是以原生形式保存二进制数据。因此，请使用BLOB。（但是，即使您确实将数据存储在Base64字符串中，也无需担心编码/解码性能，因为IO的影响将更加显著。）
我不明白为什么客户端应该用base64发送数据。为什么不使用简单的HTTP调用"流式传输"呢？