为了简单起见，假设我正在开发像Instagram这样的移动应用程序。用户可以从服务器下载图像，并上传自己的图像。目前，服务器将MySQL数据库中的所有图像（实际上只是小缩略图）存储为blob。传输图像最常见的方式似乎是使用Base64编码，这给我留下了两个选择：
- 服务器将所有图像存储为blob。要上载图像，客户端将其编码为Base64字符串，然后将其发送到服务器。服务器将图像解码回二进制格式，并将其作为BLOB存储在数据库中。当客户机请求图像时，服务器将图像重新编码为Base64字符串，并将其发送给客户机，然后客户机将其解码回二进制以供显示
- 服务器将所有图像存储为Base64字符串。要上载图像，客户端将其编码为Base64字符串并将其发送到服务器。服务器不进行编码或解码，只是将字符串存储在数据库中。当客户机请求图像时，Base64字符串返回给客户机，然后客户机对其进行解码以显示
显然，选项#1需要在服务器上进行更多的处理，因为每次请求都必须对图像进行编码/解码。这使我倾向于选项2，但一些研究表明，在MySQL中存储Base64字符串比直接将图像存储为BLOB效率低得多，通常不鼓励这样做
我当然不是第一个遇到这种情况的人，那么有没有人对实现这一目标的最佳方式提出建议
JSON采用utf8，因此与图像不兼容，除非它们以某种方式编码
Base64的体积几乎是二进制（BLOB）的8/6倍。有人可能会说，它很容易负担得起。3000个字节变成大约4000个字节
每个人都应该能够接受任意8位代码，但不是每个人都能接受。Base-64可能是不必处理8位数据的最简单和总体最佳折衷方案
因为这些是“小的”，我会把它们存储在一个表中，而不是一个文件中。但是，我会将它们存储在一个单独的表中，并在需要时通过适当的id连接它们。这允许不需要映像的查询运行得更快，因为它们没有跨过blob
从技术上讲，TEXT CHARACTER SET ascii COLLATE ascii_bin就可以了，但BLOB更清楚地表明，该列中实际上没有任何可用的文本