合理使用Blob/Clob

 用了十多年的数据库，工作需要也经常要帮忙数据库性能调优。这里简单列一些我平时工作时用数据库的体会和心得：

介绍：

虽然数据库原生支持Blob(二进制大对象）和Clob(字符串大对象），但是从性能的考虑，我们把这些内容放在数据库里面不合适的。比如说我有1个100多M的图片(Blob)，或者说我有一大段文本(Clob),这种东西是千万杜绝放在数据库中的。原因有3点。（1）加大了数据库维护和备份的成本。因为这些大数据的存在，使得我们要很多额外空间来进行数据库备份。(2)是因为数据库是一种读快写慢的系统，这就意味着如果我们要变更这些内容，会非常的不方便。比如我们要在大段文本中加或者改写内容，我们必须把这段Clob删除后再重新添加。非常费时间。(3)在现在的新系统架构中我们一般都用了分层的思想，比如说，数据库层，应用层，文件存储层，浏览器等。而在考虑到系统整体的性能的时候，往往跨越层级的访问是最大因素。而我们如果吧这些图片，大段文本都放在数据库的话，那么最简单的访问都必须要横跨多层。

解决方法：

一般我们为了处理这种Blob,Clob的数据，我们常用的解决方法是，我们可以建立一个文件服务器，然后把相应的图片，或者文本(放在某文件中）,然后把这些图片和文本放在文件服务器上，而在数据库中保存的是这些图片资源或者文本资源的路径。这样的好处有3点。(1)读写速度提升。因为 文件服务器上的内容是扁平内容，而数据库系统中的内容是结构化的数据，所以从读写效率上来说，对于文件服务器内容的读写速度要远远高于对于数据库系统的读写速度.(2)可维护性提升。如果我们把这些图片，文本放在文件服务器上，那么我们非常容易维护。因为我们如果要替换图片，或者替换文本，我们只要把新的文件取代原来位置的图片和文本就可以了，而数据库中因为保存的是引用的图片或者文本的位置，所以我们根本不需要去改那个路径。这也是一种弱耦合关系。而前面也说了，如果这些内容以LOB的形式放在数据库中的话，就算要做非常微量的改动，也必须删除原来对象然后创建新对象，这个是非常浪费时间的。(3）无需海量的备份开销。因为数据库备份很麻烦，不仅仅要备份内容，还要备份索引等。而文件系统的备份则无疑是最简单的硬盘内容的复制，所以开销很小。