数据库里用二进制存图片，这技术听起来挺新鲜也挺实用的

（根据知乎问题“数据库里用二进制存图片，这技术听起来挺新鲜也挺实用的”下的回答整理）

其实这个技术说新鲜也不算新鲜了,它很早就在数据库领域里存在了，只是平时我们普通用户不太会直接接触到而已，说它实用，那确实是实实在在的，我给你打个比方你就明白了。

文件系统存图片：就像把书放在一个大图书馆里

我们最习惯的方式,是把图片当成一个个独立的文件，张三的照片.jpg”，然后保存在服务器的某个文件夹里，/images/avatar”，数据库里呢，只记下这本书的“索书号”，也就是这个图片文件的路径，/images/avatar/zhangsan.jpg”。

• 好处是：简单、直接，管理和查看图片就像在电脑上打开文件夹一样方便，网页服务器（比如Nginx, Apache）天生就擅长快速地发送这些静态文件，效率很高。
• 麻烦是：管理和备份起来有点头疼，图片是图片，数据库是数据库，它们是分开的两家人，你想备份整个系统，得分别备份数据库和那个存图片的文件夹，还得确保它们俩是对得上号的，不然数据库里记着有这张图，但文件夹里的图可能已经被误删了，更麻烦的是，如果你的应用要扩展到多台服务器（分布式），你得想办法让所有服务器都能访问到同一个图片文件夹，这就需要搭建更复杂的共享文件系统，增加了技术难度和成本。

数据库存二进制图片：就像把书的每一页都抄录在借书卡背面

而把图片转换成二进制存进数据库,思路就完全不同了，它不再保存文件路径，而是把图片文件本身打开，读取里面所有的0和1数据，然后把这一长串二进制数据，像存一大段文字一样，存进数据库一个特定类型的字段（比如BLOB类型的字段）里。

• 好处是：管理变得超级简单，因为图片和数据“长”在了一起，你备份数据库，自然就把图片也备份了；你迁移系统，只需要搬动数据库这一个东西就行，数据的一致性得到了很好的保证，绝对不会发生“图没了，但记录还在”的尴尬，在分布式环境下，这个优势尤其明显，因为每台服务器都直接从中心数据库读数据，避免了文件同步的麻烦，而且安全性也更容易控制，你可以用数据库的权限系统来管理谁可以看哪些图片，而不是直接暴露文件路径。
• 麻烦是：这对数据库的压力比较大，图片通常都比文字大得多，数据库既要处理复杂的查询，又要吞吐这些“大块头”数据，容易不堪重负，每次读取图片，都需要数据库从自己的“肚子”里把二进制数据掏出来，再交给应用程序转换成图片，这个流程比网页服务器直接发送文件要慢一些，会消耗更多的数据库连接和计算资源，时间长了，数据库的体积会膨胀得非常快，管理和优化起来也更费劲。

那到底该怎么选呢？

这就像问“出门是坐公交还是自己开车”一样，得看具体情况。

• 适合用数据库存的情况：

  

  • 图片非常小，而且数量不多：比如用户的头像、产品的缩略图，这些图片通常只有几KB，对数据库压力不大。
  • 图片和数据的关联性极强，是机密或核心资产：比如实名认证时上传的身份证照片、医疗系统中的X光片，这些图片需要和用户信息严格绑定，并且需要数据库本身的高安全性来保护，不适合以文件形式公开存放。
  • 需要高度的事务一致性：比如你上传一张图片，必须和创建一条新记录同时成功或同时失败，利用数据库的事务功能可以轻松实现，而文件系统就不好做这一点。

• 适合用文件系统存的情况：

  • 图片量大、体积也大：比如一个视频网站的海量电影，或者一个图片分享社区的用户上传的原图，这种情况铁定要用文件系统（或更专业的对象存储，比如阿里云OSS、AWS S3），数据库根本扛不住。
  • 对访问速度要求很高：专门的网页服务器或CDN（内容分发网络）来处理静态文件，速度远比从数据库里取要快得多。
  • 图片经常被不同的应用程序使用：如果别的系统也需要读这些图，直接给个URL（文件路径）是最通用的方式。

（根据CSDN技术博客“关于图片存入数据库的优缺点分析”整理）

现在更流行的一种“中庸之道”是使用对象存储服务，你可以把它理解为一个超级智能、专门为存文件而优化的“云端文件系统”，做法是：图片上传到对象存储（比如阿里云OSS），它会返回一个唯一的网址（URL），然后你把这个URL存到数据库里，这样既享受了文件系统的高性能和易扩展性，又保持了数据管理的便利性（因为URL是存在数据库里的，备份和迁移数据库依然关键），这已经成为目前互联网应用存储图片等静态资源的主流方案。

数据库存二进制图片这项技术,并不是一个“过时”或“落后”的技术，它只是在特定的场景下有它独特的用武之地，了解它的原理和优缺点，能帮助我们在设计系统时做出最合适的选择，说到底，没有最好的技术，只有最合适的技术。