关于图片或者文件在数据库的存储方式归纳

据我了解，互联网环境中，大访问量，数据库速度和性能方面很重要。一般在数据库存储图片的做法比较少，更多的是将图片路径存储在数据库中，展示图片的时候只需要连接磁盘路径把图片载入进来即可。因为图片是属于大字段。一张图片可能1m到几m。

有个原则：图片尽量不要存储在数据库中(是指不要二进制形式保存到字段，而只保存图片的路径)。这样的大字段数据会加重数据库的负担，拖慢数据库。在大并发访问的情况下很重要。这是一个经验。去看看dba对数据库性能调优方面的分析都能得到这个答案的：就是图片不要存储在数据库中。

二、数据库中保存图片路径

一般是这样子的：

按照年月日生成路径。具体是按照年月日还是按照年月去生成路径，根据自己需要(不一定是按照日期去生成)。

理解为什么要分散到多个文件夹中去才是关键，涉及到一个原理就明白了：

操作系统对单个目录的文件数量是有限制的。当文件数量很多的时候。从目录中获取文件的速度就会越来越慢。所以为了保持速度，才要按照固定规则去分散到多个目录中去。

图片分散到磁盘路径中去。数据库字段中保存的是类似于这样子的”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://www.xxx.com/images/2012/09/25/1343287394783.jpg保存到数据库中

曾经与一个上海的网友聊天，他也是习惯不会把域名保存数据库中过去。但当时我们两聊的时候，他对”域名保存进去的做法”与”不保存域名进去”也没有一个明确利弊。他就觉得，没有什么明显的区别啊。

了解的知识越多，越有利于我们做决定。可能就是一个”感觉区别不是很大”的影响下，去做一个决定，反而对后面是比较大的影响的。至少是增加自己的工作量了。

其实把域名保存进去，也不是什么滔天大罪的事情。但凡是经验丰富的开发人员都不会这样子做。这是一个经验积累出来的，所以上海那个网友也对此并没有明显的概念很正常，他说他不知道cdn方面的(当然觉得存个域名进去没什么大不了的)。需要了解cdn知识，什么情况下会用到cdn知识。

虽然是做开发人员，不需要关注运维和服务器之类的知识。不过了解一些就有利于理解了。

这里涉及到cdn加速。