mysql字段存储base64_数据库存储图片解决方案

产品图片、用户上传的头像等图片。目前业界存储图像的方式有两种：

1.将图像直接以二进制形式存储在数据库中

一般来说，数据库提供了一个二进制字段来存储二进制数据。例如mysql中有一个blob字段。数据库是blob或bfile类型

2、图片存储在磁盘上，图片的路径保存在数据库字段中。

1.图像直接以二进制形式存储在数据库中

第一个存储实现（php语言）：

总体思路：

1. 使用PHP程序将读取的图像转换为二进制形式。然后与into语句结合，插入到数据表中的blob类型字段中。

3、从数据库中取出图片进行显示时。就是直接发送图片内容

4.

行=();

（“-类型：图像/gif”）；

回显$行->;

实现代码如下：

$ = '/tmp/.jpg';//假设这是上传的图片，php放在临时文件夹中。脚本执行后会自动删除。

=fread(fopen(, “r”);

=fread(fopen(, “r”), ($));

sql=“()()”;

注：是数据表中的blob字段类型字段

================ 取出显示图像代码

=(“*m=”) 或 die(“无法查询”);

行=();

（“-类型：图像/gif”）；

回显 $row-> ;

总结：感觉处理代码确实很麻烦。事实上，我从来没有使用过将图像以二进制形式存储在数据库中的方法。我们用的比较多的是存储图片的路径。实际图片保存在磁盘上（二进制图像放在数据库中，增加了数据库的负担）。

据我所知，在互联网环境下，访问量大，数据库的速度和性能非常重要。一般将图片存入数据库的方法较少，较多的方法是将图片路径存入数据库。显示图片时，只需连接磁盘路径并加载图片即可。因为图片属于一个大领域。一张图片可能有1m到几米长。

有一个原则：数据库中尽量不要存储图片（意思是不将二进制形式保存到字段中，而只保存图片的路径）。如此大的字段数据会增加数据库的负担，降低数据库速度。在大并发访问的情况下很重要。这是一种体验。如果你看DBA对数据库性能调优的分析，你会得到答案：不要在数据库中存储图片。

就像这样的规则：文章分为标题、作者、添加时间、更新时间、文章内容、文章关键词

文章内容一般都比较长。文本字段通常用于存储。文章内容属于大领域。一般情况下，文章内容可以拆分成单独的表格。不要将文章信息存储在同一个表中。

我理解的原理是：MySQL中一张表的数据都在一个数据文件中。如果大字段的数据也存储在里面的话。该程序显示一个列表，例如文章列表。此时不需要显示文章内容。但还是会影响速度。在数据库中查找数据实际上就是扫描数据文件。文件大小越小，速度就越快（为什么单表容量在1g-2g的时候基本都是分表的）。将其拆分为一个单独的表，即一个单独的文件。我感觉举一反三、相互独立、分离的思想不仅用在系统开发中，在现实生活中也经常存在。相互混合就会产生相互影响。小而简洁是一种思想。

你可以阅读这篇翻译文章，

作者建议，三样东西绝对不要放在数据库中：图片、文件和二进制数据。作者的理由是，

数据库的读/写速度永远跟不上文件系统处理的速度。

数据库备份变得庞大且耗时

对文件的访问需要经过你的应用层和数据库层

将图像缩略图保存到数据库中？太好了，那么你就不能使用 nginx 或其他类型的轻量级服务器来处理它们了。

让您自己更轻松，只需将磁盘上文件的相对路径存储在数据库中，或者使用 S3（注意： 云服务）或 CDN 等服务。

=================================================== =========

关于mysql中的blob类型

Bolb分为blob，，和int类型一样。其实从小到大，

blob容量为64KB，容量为16M，容量为4G。

说实话，像这样存储图片的人很少使用。使用php函数序列化该值，我看到有人将其保存到该字段中。

PHP手册：返回一个字符串。该字符串包含表示值的字节流，可以存储在任何地方。

mysql中有一个用于在blob字段中存储图片的通信大小设置：

如果要将图片传输到mysql进行存储，就需要涉及到数据通信。 mysql中有一个配置限制通信数据的大小。

my.conf配置文件中，mysql的默认值为1M。

很多图片，尤其是原图，可能会超过1m。传输的数据（即图片）超出此设置大小。结果会是错误的

哈哈，限制还是蛮多的。感觉好麻烦啊。这显然占用了与mysql交互时的通信时间。响应时间已延长。我直接将镜像路径“/xxxx”发送到mysql。它不是那么资源密集型。

其实所谓性能，最关键的就是数据库性能。因为随着数据库数据量的增大，php、java等语言大部分时间都花在了等待数据库返回数据的过程中。

网站有了大量访问量之后，具体语言不是瓶颈，瓶颈是数据库。可以使用c、php、java、net操作mysql数据库获取数据。语言之间可能存在速度执行差异，但实际上这种差异已经很小了。至少我认为这对用户来说并不明显。如果执行差异为0.0001秒，用户的感知没有明显差异。可以说，当并发量较大时（很多用户同时访问），差异就会体现出来。其实我认为大并发访问是数据库的瓶颈。等待数据库给出数据。没有达到一定的水平确实没有什么区别。数据库数据量达到一定水平。 0.001s的语言差异就会给用户体验带来差异。我想这就是为什么PHP非常适合web开发的原因。解析页面速度很快（解释语言，无需编译）。可以使用java与数据库打交道来获取数据。 PHP并不直接操作数据库，而是调用Java提供的数据接口来获取数据并立即显示在页面上。这利用了 PHP 快速的页面执行速度。

方便备份图像数据和迁移数据

图片以二进制形式存储在数据库中，这样的优点是：方便备份。直接备份数据库，图片也会备份。也就是说，迁移环境的时候比较方便。

如果图像放在磁盘上，则数据库中仅存储图像路径。备份数据库后。磁盘上的图片也必须备份。

但我认为备份的好处不是很明显。图片都在磁盘上，所以备份磁盘也没什么大不了的。也可提供包装和压缩。毕竟互联网环境与传统软件开发不同。 Web开发更注重网站速度。这就是数据库的速度。就像在互联网开发中，有时候为了速度而用空间换时间是很常见的，所以在设计数据库的时候往往不一定遵循传统数据库设计的三大范式。

如果将图片路径保存在数据库中，在Web开发环境中，其实还有一个更好的好处，就是CDN加速。这就是下面要总结的地方。

2.将图片路径保存到数据库中

它通常看起来像这样：

根据年、月、日生成路径。具体来说，是按照年月日还是年月生成路径，就看你自己的需求了（不一定是按照日期）。

关键是要明白为什么需要分散到多个文件夹中。当谈到一个原则时，你就会明白：

操作系统对单个目录中的文件数量有限制。当文件数量较多时。从目录中检索文件会变得越来越慢。因此，为了保持速度，必须按照固定的规则分散到多个目录中。

图片分散在磁盘路径上。数据库字段中保存的内容类似于“/2012/09/25/83.jpg”

原来上传的图片文件名会被重命名并保存，例如根据时间戳生成83.jpg。这是为了避免多个人将图像上传到同一目录时可能出现的文件名重复。

不管怎样，用什么样的规则来命名图片，只要图片名称唯一就可以了。

例如，如果网站并发访问量较大，则目录生成越详细越好。比如精确到小时，一小时可以是一个文件夹。同时，两个用户在 0.001 秒内同时上传图片（因为此时图片将存储在同一个小时文件夹中）。因为时间戳是精确到秒的。为了使图像名称唯一并且避免被覆盖，生成可以在时间戳后面继续添加毫秒、微秒等。一般规则是并发访问数越大。越准确越好。

我还没有遇到过需要如此精确的人。概率比较小。

这里总结一下：为什么保存的磁盘路径是“/2012/09/25/83.jpg”而不是“///2012/09/25/83.jpg”（开头有斜杠）

我的理解：

连那个斜线都没有。这样做也是为了方便以后系统的扩展。

当需要取出图片路径在页面上显示图片时，如果是相对路径，可以使用“./”+”/2012/09/25/83.jpg”进行组装。

如果你需要一个单独的域名（比如做CDN加速时）域名，这样的域名，

直接组装“”+”/2012/09/25/83.jpg”

当然数据库可以保存，前面加斜线/，//2012/09/25/83.jpg

其实统一起来也不方便。例如使用相对路径加载图片时为“.”+“//2012/09/25/83.jpg”

也许我还没有意识到缺点，以后会遇到问题。但是，只需遵循约定并省略斜杠“/2012/09/25/83.jpg”即可。

涉及到一个新问题：为什么大多数系统不保存域名，而是这样保存到数据库中？

我曾经和上海的一个网友聊天，他也习惯不将域名保存到数据库中。但当时我们聊天的时候，他对于“存域名”和“不存域名就干”并没有明确的利弊。他觉得并没有什么明显的区别。

我们拥有的知识越多，我们做出的决定就越好。可能是在“差别不是很大”的影响下，你做出的决定，却会对未来产生更大的影响。至少增加了我的工作量。

事实上，保存域名并不是什么严重的犯罪行为。但没有经验丰富的开发人员会这样做。这是经验积累的，上海网友对此不清楚也很正常。他说他不知道CDN（当然他认为省个域名没什么大不了的）。您需要了解CDN知识以及在什么情况下会使用CDN知识。

虽然你是开发人员，但不需要关注运维和服务器知识。但如果你了解一点的话，会对理解有所帮助。

这就涉及到cdn加速了。

关于cdn（即内容分发网络）原理

CDN，我理解它的本质是解决远距离带来的速度问题，使用就近服务。

从中国向美国的服务器请求图像。它通常较慢，因为在如此长的距离内网络传输存在损耗。距离越远，传输时间越长。一般情况下，您会看到浏览器左下角显示：“已回复，数据正在传输...”。这不是服务器本身的问题。事实上，服务器已经响应了请求，并将数据发送给了客户端。但由于网络问题，传输一直在进行中，尚未完成。

在中国，问题是南北距离。南北之间也将涉及跨网络。南方用户大部分使用电信，而北方用户大部分使用网通。需要跨越两条线，会有时间延迟。北京到广州的距离（如果直接要求）

CDN加速就是为了满足这个需求而生的：现在不请求美国的服务器了。直接在国内放置节点（节点是一个比较笼统的术语，可以理解为服务器，也可以理解为机房，只是一个点），请求距离较近的节点。这样就不需要那么远的距离了。

我记得以前在长沙的网站上，团购都是以城市分店的形式进行的。北京和长沙采用相同的程序。服务器在长沙。北京用户访问北京网站时，实际上需要远程访问长沙的服务器。我不能再快了。与服务器性能无关。我当时不明白这一点。不知道怎么去搅乱它。看了那个《前端优化技巧》，想办法做一些诸如js代码压缩、浏览器缓存之类的事情，其实就是瞎搞。这并不是说这些前端优化不重要。哲学上有主次矛盾，哪里有瓶颈就应该突破。主要矛盾不解决，问题就解决不了。当时还不是数据库瓶颈。如果你想优化数据库。不会有明显改善。就这么多数据。根本就没有达到瓶颈。主要矛盾在哪里？后来，当我去其他公司工作，接触一些东西时，类似的优化而没有找到瓶颈的例子在我身边发生了好几次。我只是盲目优化，没有找到瓶颈。我的同事可能是抱着越多越好的心态去做的，但主要矛盾（技术上来说是瓶颈）还没有找到，也没有得到改善。

如果我当时不认为这是距离的问题。我不会想到CDN。那时我其实根本不知道CDN服务。我只知道这些网站的服务器肯定部署在中国。否则，如果中国用户仍然访问美国的服务器，无论服务器有多好，速度都会很慢。

由于自己搭建CDN环境和机房（需要大量服务器）需要花费大量资金，同时也需要人力来维护。反正一般公司是买不起的。事实上，这根本不划算。淘宝以前使用商业CDN服务，但后来商业无法承受，所以他们建立了自己的CDN网络。我不知道是不是新浪自己打造的，但其实我觉得和淘宝的特点有关系。有很多商店。无论是产品还是交易记录，都有很多产品的图片。图片均为静态部分。 CDN 最初用于静态目的。 （图片、css、js等）用于请求分发。

之前在网上看到一句话，CDN网络不是一般企业能够承受的。

普通企业搭建自己的CDN网络成本高昂，因此出现了提供付费租赁服务的商业CDN。这是一项非常成熟的业务。许多这样的公司，包括大多数国家互联网公司，都使用 CDN。

摘要：cdn服务。它非常适合静态内容。所以像产品图片一样，随着访问量的增加，租用CDN服务只需要把图片上传到他们的服务器上就可以了。

例：北京访问长沙服务器时，距离太远。我绝对可以把产品图片放在北京的云服务上（我觉得目前为网站提供的云存储其实就是CDN，为网站提供导流和就近访问）。这样，当北京的用户访问时，图片实际上是在附近获取的。无需长距离传输。

使用域名自行加载图片。该域名解析到北京的云服务。

方法：数据库中保存的是“/2012/09/25/83.jpg”，

这些图像实际上并不存储在网络服务器上。上传到北京的cdn服务器。

我从数据库中取出来，直接“/”+“/2012/09/25/83.jpg”

例如，如果有多个，请说出它们的名称，

无论如何，你可以做任何你想做的事。所以如果直接保存域名的话。看起来很麻烦。迁移麻烦。

在淘宝、凡客、亚马逊等电商网站上，当我们看到请求时，往往会有

事实上，它们作为相对路径存储在数据库中。有的不需要保存在数据库中，实时访问时可以由程序生成缩略图（节省大量存储空间）

事实上，将域名保存在数据库中对于系统迁移是非常不利的。一旦域名改变了，数据库中原来保存的是“”，因为路径是硬编码在数据库中的。如果下次更改域名，您将无法使用该域名。到时候就可以编写SQL语句批量更新字段了。

几个术语：

icp, , 是网络内容提供商。您认为运营网站需要备案吗？如果您自己运营网站，您就是ICP服务提供商

IDC（数据），互联网数据中心。 IDC的概念目前还没有统一的标准。通俗地说，就是提供机房托管（服务器租用和托管）、域名注册等。

关于淘宝图片存储

据了解：淘宝过去使用的是商业存储。但无法满足需求。据称，到2010年，淘宝后台存储了286亿张图片。当商业系统无法满足需求时。他们自己开发了一个tfs。读取磁盘上的大规模小文件需要频繁的寻道和更换磁头。在大并发情况、大量操作的情况下确实很麻烦。事实上，它是基于当时发布的gfs设计论文。有相册服务。为每个用户提供上传图片存储。

估计是第一个实现这种小文件网络存储系统的。

有一个更好的观点：对于老板来说，往往觉得能用钱解决的问题都不是问题。但问题是你遇到的问题没有人遇到过。那么这个时候你就没有经验可以直接参考或者使用了。你只能参考一些想法才能创造出技术。

3.关于图片云存储（cdn加速）

我以前见过这个，这个比较适合初创公司。价格比较便宜

介绍中提到我们在全国部署了55个CDN节点，500多台服务器，以及中国电信、中国联通、中国移动和教育网的4线带宽。

其实现在的云存储本质上就是一个CDN服务商。你把静态图片上传到他提供的服务器上（通过ftp上传或者通过API程序上传）。它为您提供对最近节点的访问。

计费方式：按流量付费，100g 99元。如何计算流量。文件的大小在每次访问时都会累积。比如1m的文件，每次访问流量就会增加1m。

我个人理解，当图片量不大的时候，使用这个云服务的好处并不是节省存储空间。自己服务器的100g空间可能创业公司都用不完。并不是因为存储空间不够，所以使用云存储。以前我对CDN的理解比较模糊，或者以为是为了分散网站web服务器流量压力，服务器分流。好处就在那里。不过，只要了解CDN的背景和它解决的关键问题，你就会明白云存储的关键好处是为用户提供就近节点的访问并加速。

我觉得如果没有这个考虑，是达不到这样的目的的。它可以完全被其他解决方案替代。为什么要使用云存储？只有你有实力在全国多个节点部署服务才需要租用CDN来帮你。毕竟，他们是规模效益，专注于解决这方面的问题。

另：腾讯云、阿里云