189 8069 5689
此实现为用java访问mysql的blob,对图片进行存取
创新互联从2013年开始，先为长汀等服务建站，长汀等地企业，进行企业商务咨询服务。为长汀企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
/**
* Title: BlobPros.java
* Project: test
* Description: 把图片存入mysql中的blob字段，并取出
* Call Module: mtools数据库中的tmp表
* File: C:downloadsluozsh.jpg
* Copyright: Copyright (c) 2003-2003
* Company: uniware
* Create Date: 2002.12.5
* @Author: ChenQH
* @version 1.0 版本*
*
* Revision history
* Name Date Description
* ---- ---- -----------
* Chenqh 2003.12.5 对图片进行存取
*
* note: 要把数据库中的Blob字段设为longblob
*
*/
//package com.uniware;
import java.io.*;
import java.util.*;
import java.sql.*;
public class BlobPros
{
private static final String URL = "jdbc:mysql://10.144.123.63:3306/mtools?user=windpassword=123useUnicode=true";
private Connection conn = null;
private PreparedStatement pstmt = null;
private ResultSet rs = null;
private File file = null;
public BlobPros()
{
}
/**
* 向数据库中插入一个新的BLOB对象(图片)
* @param infile 要输入的数据文件
* @throws java.lang.Exception
*/
public void blobInsert(String infile) throws Exception
{
FileInputStream fis = null;
try
{
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
conn = DriverManager.getConnection(URL);
file = new File(infile);
fis = new FileInputStream(file);
//InputStream fis = new FileInputStream(infile);
pstmt = conn.prepareStatement("insert into tmp(descs,pic) values(?,?)");
pstmt.setString(1,file.getName()); //把传过来的第一个参数设为文件名
//pstmt.setBinaryStream(2,fis,(int)file.length()); //这种方法原理上会丢数据，因为file.length()返回的是long型
pstmt.setBinaryStream(2,fis,fis.available()); //第二个参数为文件的内容
pstmt.executeUpdate();
}
catch(Exception ex)
{
System.out.println("[blobInsert error : ]" + ex.toString());
}
finally
{
//关闭所打开的对像//
pstmt.close();
fis.close();
conn.close();
}
}
/**
* 从数据库中读出BLOB对象
* @param outfile 输出的数据文件
* @param picID 要取的图片在数据库中的ID
* @throws java.lang.Exception
*/
public void blobRead(String outfile,int picID) throws Exception
{
FileOutputStream fos = null;
InputStream is = null;
byte[] Buffer = new byte[4096];
try
{
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
conn = DriverManager.getConnection(URL);
pstmt = conn.prepareStatement("select pic from tmp where id=?");
pstmt.setInt(1,picID); //传入要取的图片的ID
rs = pstmt.executeQuery();
rs.next();
file = new File(outfile);
if(!file.exists())
{
file.createNewFile(); //如果文件不存在，则创建
}
fos = new FileOutputStream(file);
is = rs.getBinaryStream("pic");
int size = 0;
/* while(size != -1)
{
size = is.read(Buffer); //从数据库中一段一段的读出数据
//System.out.println(size);
if(size != -1) //-1表示读到了文件末
fos.write(Buffer,0,size);
} */
while((size = is.read(Buffer)) != -1)
{
//System.out.println(size);
fos.write(Buffer,0,size);
}
}
catch(Exception e)
{
System.out.println("[OutPutFile error : ]" + e.getMessage());
}
finally
{
//关闭用到的资源
fos.close();
rs.close();
pstmt.close();
conn.close();
}
}
public static void main(String[] args)
{
try
{
BlobPros blob = new BlobPros();
//blob.blobInsert("C:Downloadsluozsh1.jpg");
blob.blobRead("c:/downloads/1.jpg",47);
}
catch(Exception e)
{
System.out.println("[Main func error: ]" + e.getMessage());
}
}
}
存图片的路径只需要最后的 \microMsg.2.jpg （之前的一截存数据库浪费空间）
之前的一截，用配置文件写好，跟网络访问路径对应就好了，
你就把一张图片当成一个servlet来看待就好了
记得在web服务器上配置访问路径跟图片路径的映射关系，不是自己的电脑，没有例子
表格显示控件是刷新率比较慢的一类控件，的确容易造成闪烁，有如下几个办法改善闪烁：
a) 如果系统对采样率要求不高，加一个延时，一般延时300ms或以上时，就不会闪烁了
b) 如果系统无法延时这么长时间，请在前面板的【表格显示控件】上单击右键，选第一行【显示项】，把【垂直滚动条】和【水平滚动条】的勾选去掉，会明显改善闪烁。
c) 还有一个方法就是加一个CASE结构，把【表格】放在【CASE】里面，每隔500ms才刷新一次表格。
另一个方法是使用字符串显示控件。这个控件刷新速度非常快，不会有任何闪烁，但是有两个缺点，第一是需要把字符串预先连接起来，第二是没有表格线。
下面是附图：
图1.a ：延时300毫秒
图1.b ：取消垂直和水平滚动条
图1.c ：每500次循环刷新表格一次
图2 ：用字符串显示控件代替表格
下图是效果：
商品图片，用户上传的头像，其他方面的图片。目前业界存储图片有两种做法：
1、 把图片直接以二进制形式存储在数据库中
一般数据库提供一个二进制字段来存储二进制数据。比如MySQL中有个blob字段。Oracle数据库中是blob或bfile类型
2、 图片存储在磁盘上，数据库字段中保存的是图片的路径。
一、图片以二进制形式直接存储在数据库中
第一种存储实现(PHP语言)：
大体思路：
1、将读取到的图片用php程序转化成二进制形式。再结合insert into 语句插入数据表中的blob类型字段中去。
3、 从数据库取出图片展示的时候。则是直接发送图片内容
4、
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row-this_image;
实现代码如下：
$PicturePath = ‘/tmp/xxxjgjgj.jpg’;//假设这是上传的图片，php放在一个临时文件夹。脚本执行完毕后自动删除了。
$imgStream = fread(fopen($PicturePath, "r");
$blob_img = fread(fopen($imgStream, "r"), filesize($PicturePath));
$sql =” INSERT INTO Images (this_image) VALUES ($blob_img)";
注：this_image就是数据表中一个blob字段类型的字段
================取出展示图片代码
$result=mysql_query("SELECT * FROM Images WHERE PicNum=$PicNum") or die("Cant perform Query");
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row- this_image;
总结：处理代码感觉还真比较麻烦。其实，我从来没用过在数据库中以二进制存储图片的做法。我们用得更多的是存储图片的路径，实际图片是在磁盘上保存的(图片二进制放到数据库,把数据库的负担弄重了)。
据我了解，互联网环境中，大访问量，数据库速度和性能方面很重要。一般在数据库存储图片的做法比较少，更多的是将图片路径存储在数据库中，展示图片的时候只需要连接磁盘路径把图片载入进来即可。因为图片是属于大字段。一张图片可能1m到几m。
有个原则：图片尽量不要存储在数据库中(是指不要二进制形式保存到字段，而只保存图片的路径)。这样的大字段数据会加重数据库的负担，拖慢数据库。在大并发访问的情况下很重要。这是一个经验。去看看dba对数据库性能调优方面的分析都能得到这个答案的：就是图片不要存储在数据库中。
就像这个规则一样：文章分为标题、作者、添加时间、更新时间、文章内容、文章关键字
文章内容一般是比较长的。经常使用text字段去存储。文章的内容就属于大字段。一般文章内容可以拆分到单独一个表中去。不要与文章信息存储在一张表里面。
我理解的原理是：mysql中一张表的数据是全部在一个数据文件中的。如果大字段的数据也存储在里面。程序展示列表，比如文章列表。这个时候根本不需要展示文章内容的。但是仍然会影响速度，数据库查找数据其实就是扫描那个数据文件，文件容量越小，速度就会越快(为什么单表的容量在1g-2g的时候基本上要分表了)。拆分出去到一张单独的表，就是单独的文件了。我觉得，举一反三，相互独立，分离的思想不仅在系统开发中用到，在现实生活中经常存在的。相互混合，就会造成相互影响。小巧，简洁是一种思想。
可以看看这篇翻译的文章，
http//developer.51cto.com/art/201211/364472.htm
作者建议，三种东西永远不要放到数据库里,图片，文件，二进制数据。作者的理由是，
对数据库的读/写的速度永远都赶不上文件系统处理的速度
数据库备份变的巨大，越来越耗时间
对文件的访问需要穿越你的应用层和数据库层
把图片缩略图存到数据库里？很好，那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。
给自己行个方便吧，在数据库里只简单的存放一个磁盘上你的文件的相对路径，或者使用S3（备注：亚马逊云服务）或CDN之类的服务。
============================================================
关于mysql中的blob类型
bolb像int型那样，分为blob、MEDIUMBLOB、LONGBLOB。其实就是从小到大，
blob 容量为64KB ，MEDIUMBLOB 容量为16M，LONGBLOB 容量为4G。
说实话，图片用这样子存储用得还真少。使用php函数serialize进行序列化的值，我看到有人存入这个字段中去。
php手册：serialize返回字符串，此字符串包含了表示 value 的字节流，可以存储于任何地方。
mysql中blob字段存储图片有个通信大小的设置：
图片要传输给mysql存储起来，那么需要涉及到数据通信。mysql中有个配置是限制通信数据大小的。
my.conf配置文件中的max_allowed_packet，mysql默认的值是1M。
好多图片尤其是原始图可能不止1m。传输的数据(也就是图片)超过这个设置大小。结果就会出错
呵呵，限制挺多。感觉好麻烦。这样子明显占用与mysql交互的通信时间嘛。延长响应时长了。我直接丢个图片路径”images/xxxx”给mysql。没这么耗费资源。
其实所谓的性能，最关键是数据库性能。因为随着数据库数据量增大，大部分时间耗费是在php，Java等语言等待数据库返回数据的过程中耗费时间。
网站访问量大了后，具体的语言不是瓶颈，瓶颈都在数据库。用c，，php，java,net都能操作mysql数据库获取数据。语言之间可能存在速度执行差异，但是其实这种差别已经很小了。至少我觉得，给予用户感觉不到明显。执行相差0.0001秒用户感觉并没有明显的区别。可能说，大并发(很多用户同时访问)的时候，就会体现到差别了。其实我觉得，大并发访问是数据库瓶颈。等待数据库给予数据。没达到一定级别实在体现不了差别。数据库数据量达到一定级别。语言相差0.001s会给予用户体验上的差别。我想，这也是为什么php很适合做web开发了。解析页面速度快(解释型语言，不需要编译)。可以用java来与数据库打交道获取数据。php不直接操作数据库，而是调用java提供的数据接口，获取数据，马上展示在页面中。这是利用了php的页面执行速度快的一个优势。
备份图片数据和迁移数据方便
图片以二进制形式存储在数据库，有一个好处：备份的时候方便。直接备份数据库，图片也跟着备份。换句话说，迁移环境的时候是方便。
而图片放在磁盘上的话，数据库中存储的只是图片路径。备份数据库后。磁盘上的图片也要跟着备份才行。
不过我觉得，备份这个好处不是很明显。图片在磁盘上，备份磁盘也没很大的事情。打包压缩也可以了。互联网环境毕竟与传统的软件开发不同，web开发比较关注网站速度。也就是数据库的速度。就像互联网开发中，有时候为了速度，用空间换时间的做法比较普遍，所以往往在设计数据库的时候并不一定遵循传统数据库设计三大范式。
数据库中保存的是图片路径的话，在web开发环境下，其实有个更好处，就是cdn加速。就是下面要进行总结的地方。
二、数据库中保存图片路径
一般是这样子的：
按照年月日生成路径。具体是按照年月日还是按照年月去生成路径，根据自己需要(不一定是按照日期去生成)。
理解为什么要分散到多个文件夹中去才是关键，涉及到一个原理就明白了：
操作系统对单个目录的文件数量是有限制的。当文件数量很多的时候。从目录中获取文件的速度就会越来越慢。所以为了保持速度，才要按照固定规则去分散到多个目录中去。
图片分散到磁盘路径中去。数据库字段中保存的是类似于这样子的”images/2012/09/25/ 1343287394783.jpg”
原来上传的图片文件名称会重新命名保存，比如按照时间戳来生成，1343287394783. jpg。这样子是为了避免文件名重复，多个人往同一个目录上传图片的时候会出现。
反正用什么样的规则命名图片，只要做到图片名称的唯一性即可。
比如网站的并发访问量大，目录的生成分得月细越好。比如精确到小时，一个小时都可以是一个文件夹。同时0.001秒有两个用户同时在上传图片(因为那么就会往同一个小时文件夹里面存图片)。因为时间戳是精确到秒的。为了做到图片名称唯一性而不至于覆盖，生成可以在在时间戳后面继续加毫秒微秒等。总结的规律是，并发访问量越大。就越精确就好了。
我现在还没碰到需要这么精细的。概率比较少。
有个方面总结一下：为什么保存的磁盘路径，是”images/2012/09/25/1343287394783.jpg”，而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面带有斜杠)
我的理解：
连那个斜杠都不要。这里也是做到方便以后系统扩展。
在页面中需要取出图片路径展示图片的时候，如果是相对路径，则可以使用”./”+”images/2012/09/25/1343287394783.jpg”进行组装。
如果需要单独的域名(比如做cdn加速的时候)域名，img1.xxx.com,img2.xxx.com这样的域名，
直接组装 “http//img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”
当然数据库是可以在前面加斜杠/保存起来,/images/2012/09/25/ 1343287394783.jpg
其实不方便统一。比如相对路径载入图片的时候，则是”.”+” /images/2012/09/25/ 1343287394783.jpg”
可能我还没体会到坏处，以后会遇到问题的。不过，遵循惯例不加斜杠” images/2012/09/25/ 1343287394783.jpg”就对了。
涉及到一个新问题：为什么大部分系统都不会域名保存进去，像这样子http//wwwxxx.com/images/2012/09/25/1343287394783.jpg保存到数据库中
曾经与一个上海的网友聊天，他也是习惯不会把域名保存数据库中过去。但当时我们两聊的时候，他对”域名保存进去的做法”与”不保存域名进去”也没有一个明确利弊。他就觉得，没有什么明显的区别啊。
了解的知识越多，越有利于我们做决定。可能就是一个”感觉区别不是很大”的影响下，去做一个决定，反而对后面是比较大的影响的。至少是增加自己的工作量了。
其实把域名保存进去，也不是什么滔天大罪的事情。但凡是经验丰富的开发人员都不会这样子做。这是一个经验积累出来的，所以上海那个网友也对此并没有明显的概念很正常，他说他不知道cdn方面的(当然觉得存个域名进去没什么大不了的)。需要了解cdn知识，什么情况下会用到cdn知识。
虽然是做开发人员，不需要关注运维和服务器之类的知识。不过了解一些就有利于理解了。
这里涉及到cdn加速。
关于cdn原理(就是内容分发网络)
cdn，我理解其本质就是为了解决距离远产生的速度问题，使用就近的服务。
从中国请求美国一台服务器上的图片。一般比较慢，因为距离这么远，网络传输是存在损耗的，距离越远，传输的时间就越长。一般会看到浏览器左下角显示：“已响应,正在传输数据..”。这不是服务器本身问题了。实际上服务器早就响应请求，把数据发给客户端，但是网络问题，就一直在传输，没传完了。
在中国，是南北距离远的问题。南北还会涉及到跨网，南方用户使用电信居多，北方用户网通居多。两个线路需要跨越，会有时间延迟。北京到广州的距离，如果直接请求
cdn加速就是适应这个需求产生的：现在不请求美国的服务器。直接在中国安放节点(节点是比较笼统的词语，可以理解成一台服务器，也可以理解成一个机房，就是一个点嘛)，请求距离近的节点。这样子就不需要那么远的距离了。
记得以前在长沙的网站，团购以城市分站的形式。北京和长沙用的是同一套程序。服务器在长沙。北京用户访问北京站的时候,实际上需要远距离访问长沙的服务器。速度怎么都快不起来。跟服务器性能完全没关系。当时不懂这些。不清楚怎么折腾。看那本《前端优化技巧》，想办法去做js代码压缩，浏览器缓存之类的。实际上瞎折腾。不是说这些前端优化不重要，哲学上有主次矛盾之分，瓶颈在哪里就去突破哪里。没解决主要矛盾，问题并不会迎刃而解。当时也不是数据库瓶颈。如果去优化数据库。也不会明显改善。就那点数据量。根本就达不到瓶颈。哪里谈得上主要矛盾。随着后来去其他公司工作，接触一些东西，类似不找瓶颈的优化例子发生在身边好几次了，先没找到瓶颈就瞎去优化。我的同事可能是抱着多多益善的心态去做的，但主要矛盾(技术上说是瓶颈)没找到，也没改善。
当时如果没想到是距离问题。也就不会想到cdn，当时其实我根本不知道cdn服务。我只知道，google这些网站肯定在中国部署的服务器，要不然，中国用户还去访问美国的服务器，那再好的服务器都会速度慢的。
由于自己搭建cdn环境和机房的资金比较大（需要大量的服务器），也需要人力维护。反正一般的公司弄不起，其实根本不划算。淘宝以前用商用的cdn服务，后来商用的扛不住了，就搭建了自己的cdn网。我不知道新浪有没有自己搭建，但其实我觉得跟淘宝的特点有关，店铺很多，无论是商品还是交易记录总计起来商品很多的图片，图片都是静态的部分，cdn本来就是用来做静态的(图片，css，js等)请求分发用的。
我之前在网上看到一句话，cdn网络不是一般的公司玩得起的。
一般的公司自己搭建cdn网络成本高，所以就有商业的cdn提供付费租用服务，这是一项很成熟的业务，很多这样的公司，大部分全国性的互联网公司都会使用到cdn。
总结：cdn服务。对于静态内容是非常适合的。所以像商品图片，随着访问量大了后，租用cdn服务，只需要把图片上传到他们的服务器上去。
例子：北京访问长沙服务器，距离太远。我完全可以把商品图片，放到北京的云服务（我觉得现在提供给网站使用的云存储其实就是cdn，给网站提供分流和就近访问）上去。这样子北京用户访问的时候，实际上图片就是就近获取。不需要很长距离的传输。
自己用一个域名img.xxxcom来载入图片。这个域名解析到北京的云服务上去。
做法:数据库中保存的是” images/2012/09/25/1343287394783.jpg”,
这些图片实际上不存储在web服务器上。上传到北京的cdn服务器上去。
我从数据库取出来，直接”img.xxxcom/”+” images/2012/09/25/1343287394783.jpg”
比如如果还有多个，就命名img1.xxcom、img2.xxcom
反正可以随便。所以如果把域名直接保存进去。就显得很麻烦了。迁移麻烦。
像淘宝，凡客，亚马逊这些电子商务网站，我们看到请求的时候，下面往往会有
img1.xxx.cdncom
img2.xxx.cdncom
其实他们保存在数据库中的是相对路径。有些是不需要在数据库保存的，缩略图可以实时访问的时候用程序生成(节省很多存储空间)
实际上，把域名保存在数据库中，非常不利于系统迁移。一旦换个域名的话，原来保存在数据库中的是“wwwabc.om/images/xxxxxx“,因为路径都在数据库中写死了。下回换个域名就用不了了。那个时候自己去写sql语句批量更新字段吧。
几个术语：
icp，Internet Content Provider，也就是网络内容提供者。联想到我们运营一个网站需要icp备案了吗？你自己运营网站，你就是icp服务商
IDC（Internet Data Center)，互联网数据中心。IDC的概念，目前还没有一个统一的标准。通俗点，就是提供机房托管(服务器租用和托管)，域名注册之类的。
关于淘宝的图片存储
了解到：淘宝以前使用了商用的存储。但是没法满足需求。据说，到2010年，淘宝网后端保存着286亿张图片。商用的系统系统没法满足需求的时候。他们就自己开发了一个tfs。大规模的小文件在磁盘上读取，需要磁盘磁头频繁的寻道和换道。大并发情况下和大量的操作确实很麻烦。其实借鉴了当时google公布的gfs设计论文。google有相册服务。为每个用户提供上传图片存储。
估计，google是率先实现这种小文件网络存储系统的。
有个观点比较好：对于老板们而言，往往觉得，用钱能解决的都不算问题。但问题在于，你遇到的问题，别人都没遇到过。那这个时候你就没有经验可以参考或者直接拿来使用。只有自己参考一些思路去创造技术了。
三、关于图片进行云存储(cdn加速)
曾经看过这个，这个是比较适合创业公司的。价格相对便宜
https//wwwupyun.com/
介绍提到，我们在全国各地部署了55个CDN节点，500多台服务器，电信，联通，移动和教育网的4线带宽。
其实，现在的云存储本质就是一个cdn服务商。你把静态的图片上传到他提供的服务器上去(ftp方式上传或者api形式编写程序上传)。他为你做就近节点访问。
计费方式：按照流量付费，99元购买100g。怎么算流量。每次访问文件的大小累加，比如一个1m的文件，访问一次流量就加1m。
我个人理解，对于图片的量不大的情况下，使用这种云服务，好处不是节省存储空间。你自己的服务器100g的空间可能创业型公司都没用完，不是什么存储空间不够用，然后去用云存储。以前我对cdn比较模糊，有这么点理解，或者以为是分散网站web服务器流压力，服务器分流。这些好处是有的。但是，只要理解了cdn产生的背景和解决的关键问题后，就会明白云存储关键好处在于：给用户就近节点访问，加速。
我觉得，如果不是出于这个考虑，或者达不到这样的目的。用其他方案也完全可以替代。何必使用云存储呢？就是你无非有实力做到全国多个节点去部署服务，才需要租用cdn来帮你，毕竟他们是规模产生的效益，专注于解决这个领域。
背景
MySQL 一直以来都有 TEXT、BLOB 等类型用来存储图片、视频等大对象信息。比如一张图片，随便一张都 5M 以上。视频也是，随便一部视频就是 2G 以上。
假设用 MySQL 来存放电影视频等信息，一部是 2G，那么存储 1000 部就是 2TB，2TB 也就是 1000 条记录而已，但是对数据库性能来说，不仅仅是看记录数量，更主要的还得看占用磁盘空间大小。空间大了，所有以前的经验啥的都失效了。
所以一般来说存放这类信息，也就是存储他们的存放路径，至于文件本身存放在哪里，那这就不是数据库考虑的范畴了。数据库只关心怎么来的快，怎么来的小。
举例
虽然不推荐 MySQL 这样做，但是也得知道 MySQL 该怎么做才行，做到心里有数。比如下面一张微信图片，大概 5M 的样子。
root@ytt:/var/lib/mysql-files# ls -sihl 微信图片_20190711095019.jpg274501 5.4M -rw-r--r-- 1 root root 5.4M Jul 11 07:17 微信图片_20190711095019.jpg
拷贝 100 份这样的图片来测试
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`; do cp 微信图片_20190711095019.jpg "$i".jpg;done;
root@ytt:/var/lib/mysql-files# ls
100.jpg 17.jpg 25.jpg 33.jpg 41.jpg 4.jpg 58.jpg 66.jpg 74.jpg 82.jpg 90.jpg 99.jpg f8.tsv
10.jpg 18.jpg 26.jpg 34.jpg 42.jpg 50.jpg 59.jpg 67.jpg 75.jpg 83.jpg 91.jpg 9.jpg 微信图片_20190711095019.jpg
1111.jpg 19.jpg 27.jpg 35.jpg 43.jpg 51.jpg 5.jpg 68.jpg 76.jpg 84.jpg 92.jpg f1.tsv
11.jpg 1.jpg 28.jpg 36.jpg 44.jpg 52.jpg 60.jpg 69.jpg 77.jpg 85.jpg 93.jpg f2.tsv
12.jpg 20.jpg 29.jpg 37.jpg 45.jpg 53.jpg 61.jpg 6.jpg 78.jpg 86.jpg 94.jpg f3.tsv
13.jpg 21.jpg 2.jpg 38.jpg 46.jpg 54.jpg 62.jpg 70.jpg 79.jpg 87.jpg 95.jpg f4.tsv
14.jpg 22.jpg 30.jpg 39.jpg 47.jpg 55.jpg 63.jpg 71.jpg 7.jpg 88.jpg 96.jpg f5.tsv
15.jpg 23.jpg 31.jpg 3.jpg 48.jpg 56.jpg 64.jpg 72.jpg 80.jpg 89.jpg 97.jpg f6.tsv
16.jpg 24.jpg 32.jpg 40.jpg 49.jpg 57.jpg 65.jpg 73.jpg 81.jpg 8.jpg 98.jpg f7.tsv
我们建三张表，分别用 LONGBLOB、LONGTEXT 和 VARCHAR 来存储这些图片信息
mysql show create table tt_image1G
*************************** 1. row ***************************
Table: tt_image1
Create Table: CREATE TABLE `tt_image1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longblob,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql show create table tt_image2G
*************************** 1. row ***************************
Table: tt_image2
Create Table: CREATE TABLE `tt_image2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longtext,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql show create table tt_image3G
*************************** 1. row ***************************
Table: tt_image3
Create Table: CREATE TABLE `tt_image3` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
我们来给三张表插入 100 张图片（插入前，建议把 max_allowed_packet 设置到最大）
tt_image1
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image1(image_file)
values (load_file('/var/lib/mysql-files/$i.jpg'))";done;
tt_image2
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image2(image_file)
values (hex(load_file('/var/lib/mysql-files/$i.jpg')))";done;
tt_image3
root@ytt:/var/lib/mysql-files# aa='begin;';for i in `seq 1 100`;
do aa=$aa"insert into ytt.tt_image3(image_file) values
('/var/lib/mysql-files/$i.jpg');";
done;aa=$aa'commit;';mysql -S /var/run/mysqld/mysqld.sock -e "`echo $aa`";
检查下三张表记录数
mysql select 'tt_image1' as name ,count(*) from tt_image1 union allselect 'tt_image2',count(*) from tt_image2 union all select 'tt_image3', count(*) from tt_image3;+-----------+----------+| name | count(*) |+-----------+----------+| tt_image1 | 100 || tt_image2 | 100 || tt_image3 | 100 |+-----------+----------+3 rows in set (0.00 sec)
看下文件大小，可以看到实际大小排名，LONGTEXT 字段存储的最大，LONGBLOB 字段缩小到一半，最小的是存储图片路径的表 tt_image3。所以这里从存储空间来看，存放路径最占优势。
root@ytt:/var/lib/mysql/ytt# ls -silhS tt_image*274603 1.1G -rw-r----- 1 mysql mysql 1.1G Jul 11 07:27 tt_image2.ibd274602 545M -rw-r----- 1 mysql mysql 544M Jul 11 07:26 tt_image1.ibd274605 80K -rw-r----- 1 mysql mysql 112K Jul 11 07:27 tt_image3.ibd
那么怎么把图片取出来呢？
tt_image3 肯定是最容易的
mysql select * from tt_image3;+----+----------------------------+| id | image_file |+----+----------------------------+| 1 | /var/lib/mysql-files/1.jpg |+----+----------------------------+...100 rows in set (0.00 sec)
tt_image1 直接导出来二进制文件即可，下面我写了个存储过程，导出所有图片。
mysql DELIMITER $$mysql USE `ytt`$$mysql DROP PROCEDURE IF EXISTS `sp_get_image`$$mysql CREATE DEFINER=`ytt`@`localhost` PROCEDURE `sp_get_image`()mysql BEGIN DECLARE i,cnt INT DEFAULT 0; SELECT COUNT(*) FROM tt_image1 WHERE 1 INTO cnt; WHILE i cnt DO SET @stmt = CONCAT('select image_file from tt_image1 limit ',i,',1 into dumpfile ''/var/lib/mysql-files/image',i,'.jpg'''); PREPARE s1 FROM @stmt; EXECUTE s1; DROP PREPARE s1; SET i = i + 1; END WHILE; END$$mysql DELIMITER ;mysql call sp_get_image;
tt_image2 类似，把 select 语句里 image_file 变为 unhex(image_file) 即可。
总结
这里我举了个用 MySQL 来存放图片的例子，总的来说有以下三点：
占用磁盘空间大（这样会带来各种各样的功能与性能问题，比如备份，写入，读取操作等）
使用不易
还是推荐用文件路径来代替实际的文件内容存放
自己把路径中的\换成\\
即C:\ABC\A.jpg 换成 C:\\ABC\\A.jpg
否则\及其后面的字符 合起来 会被当成转义符