所以我正在 php 中做一些事情，我必须从 sql 数据库中获取我的图像，它们将在 base64 中编码。显示这些图像的速度很关键，所以我试图弄清楚将数据库数据转换为图像文件然后将其加载到浏览器中是否会更快，或者只是回显原始 base64 数据并使用：
<img src="data:image/jpeg;base64,/9j/4AAQ..." />
FireFox 和其他 Gecko 浏览器都支持。
所以回顾一下，传输实际图像文件或 base64 代码会更快吗？使用ajax加载图片需要更少的http请求吗？
图像总大小不超过 100 像素。
【问题讨论】：
标签： php mysql html image base64
【讨论】：
嗯，我不同意你们中的任何人。在某些情况下，您必须加载越来越多的图像。并非所有页面都包含 3 张图片。实际上，我正在一个需要加载 200 多张图片的网站上工作。当 100000 个用户在一个负载非常大的网站上请求 200 张图片时会发生什么。服务器的磁盘，返回图像应该崩溃。更糟糕的是，您必须向服务器发出如此多的请求，而不是使用 base64。对于这么多缩略图，我更喜欢 base64 表示，预先保存在数据库中。我在http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/ 找到了解决方案和强有力的论据。这家伙真的是那种情况，做了一些测试。我印象深刻，也进行了测试。现实就像它说的那样。对于在一个页面中加载的这么多图像，来自服务器的一个响应确实很有帮助。
【讨论】：
如果不修改，为什么要一次又一次地重新生成图像。假设，即使基于 1000 个不同的条件要显示 1000 个不同的可能图像，我仍然认为磁盘上的 1000 个图像更好。请记住，基于磁盘的图像可以被浏览器缓存并节省带宽等。
【讨论】：
这是一个非常快速和简单的解决方案。虽然图片大小会增加 33% 左右，但使用 base64 会显着减少 http 请求的数量。
Google 图片和 Yahoo 图片使用 base64 并内联提供图片。检查源代码，你会看到它。
当然，这种方法也有缺点，但我相信收益大于成本。 我发现的一个缺点是慢速设备。例如，在 iPhone 3GS 中，由 google 图像提供的图像渲染速度非常慢，因为图像是从服务器 gzip 压缩的，并且必须在浏览器中解压缩。因此，如果客户的设备速度较慢，则在渲染图像时会受到一些影响。
【讨论】：
为了回答最初的问题，我进行了一个测试，测量 400x300 像素、96 ppi 的 jpeg 图像：
base64ImageData.Length
177732
bitmap.Length
129882
【讨论】：
我曾经为图标使用过一次或两次 base64 图像（10x10 像素左右）。
【讨论】：
不要认为data:// 在 IE7 或更低版本中工作。
当请求图像时，您可以将其保存到文件系统，然后从那时起提供该图像。如果数据库中的图像数据发生更改，则只需删除该文件。也可以从另一个域（例如 img.domain.com）提供它。您可以从您的网络服务器免费获得上次修改或电子标签的所有好处，而无需启动 PHP，除非您也需要。
如果您使用的是 apache：
# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
【讨论】：
一般来说，使用 base64 编码会使字节大小增加大约 1/3。因此，您必须将 1/3 字节从数据库移动到服务器，然后再通过网络将这些额外的 1/3 字节移动到浏览器。
当然，随着图片大小的增长，所提到的开销也会成比例的增加。
话虽如此，我认为将文件更改为它们在数据库中的字节表示形式并传输它们是个好主意。
【讨论】：
回答 OP 问题。 作为静态文件，直接通过磁盘通过网络服务器。 它们只有 100 像素，非常适合 Web 服务器的内存缓存。 几乎所有的网络服务器都有大量的信息、缓存策略、配置、操作方法。
Infact - 就用户体验（您所指的图像速度）而言，最佳选择是使用支持 CDN 的对象存储。期间。
“数据库”作为静态存储选择非常昂贵 - 就所有开销处理、数据库负担、财务和技术债务而言。
一些事情，来自几个答案
Google 图片和 Yahoo 图片使用 base64 并提供图片 排队。检查源代码，你会看到它。
没有。他们绝对不会。图像主要来自静态文件“网络服务器”，特别是 gstatic.com： 例如https://ssl.gstatic.com/gb/images/p1_2446527d.png
compact - 你只有一个文件。如果文件被压缩，base64 图像几乎被压缩到正常图像的大小。
那么实际上，一点优势都没有，加上需要压缩的处理？
页面在单个请求中检索。 同样，多个并行请求而不是单个更大的负载。
当 100000 个用户请求在一个非常 加载网站。服务器的磁盘，返回图像应该 坍塌。 您仍将发送相同数量的数据，但连接时间更长，并且会给您的数据库带来压力。其次，工厂站点运行具有 100000 个并发连接的可能性......即使是这样，如果您在单个服务器上运行这一切，您就是一个愚蠢的管理员。
通过将图像 - 二进制 blob 或 base64 存储在数据库中，您所做的一切都会给数据库增加巨大的开销。要么，你有大量的 RAM，要么你通过数据库的查询无论如何都会从磁盘上掉下来。 而且，如果您确实拥有如此无限的 RAM，那么从 Ramdisk 提供 bin 图像 - 理想情况下，通过替代的专用、轻量级 Web 服务器静态文件和缓存优化，在子域上配置，将是最快、最轻的负载！
前瞻性规划？到目前为止，您只能扩大规模，并且扩大数据库的成本很高（相对而言）。再次，您说的磁盘将“sp
在这种情况下，如果您为 100000 个并发用户提供 100 张图片，则图片的服务应该是 CDN 对象存储的域。
【讨论】：
如果您想要最快的速度，那么您应该在上传/修改它们时将它们写入磁盘，并让网络服务器提供静态文件。 Rojoca 的建议也很好，因为它们最大限度地减少了 php 的调用。从另一个域提供服务的另一个好处是（大多数）浏览器将并行发出请求。
除此之外，当您查询数据时，请检查它是否上次修改，然后将其写入磁盘并从那里提供服务。您需要确保尊重 If-Modified-Since 标头，以免不必要地传输数据。
如果您无法写入磁盘或其他缓存，那么将其作为二进制数据存储在数据库中并将其流出是最快的。此时调整缓冲区大小会有所帮助。
【讨论】：