有这么个事情，有家外资企业，说大不大，说小不小。反正就是挺有钱的。他们找到我们要做个数据库优化的事情，优化什么呢，就是想做文字查找。但是现在数据库太慢了。而且经常无故崩溃。

我去看了一下，顿时被之前开发人员的高超思维给惊呆了。首先我们先来说说数据库实际使用情况，他们把几乎所有的文件重要不重要的都存放在这个数据库里。文件有各式各样，有宣传文章，邮件，合同等等。数据库非常庞大。反正仅仅是拷贝数据库文件基本一个上午。我不是说导出，就是直接考文件。

让后杰作来了，因为文件格式多样，比如有的文件有主标题，副标题，有的没有，有的有分段标题，有的有签名。结果程序员是怎么做的呢，他为了避免程序动态的开字段，干脆把所有内容都存放在一个字段里。内容用标记隔开。标记是可以自定义的。这样就可以适应不同文档的读取了。查询也方便了，就一个 like'%%' 大家懂的。但是这样搜索起来自然效率奇慢，除了有分类可以做索引，其他都得在那个字段里用like。

数据库其实没有崩溃，就是因为搜索太慢了，连接数达到上限，程序报错了。很显然早期的开发者为了赶活就想出这么个绝招。而刚应用的时候数据才能有多少。根本看不出毛病，日积月累，那个数据库自然就越来越慢。慢到根本来不及响应搜索请求自然也废了。

怎么办呢，有人说Nosql啊。可是。。。。我已经岁数很大了，拜托，这种时髦的技术只听过名字根本不知道啥玩样。再说了，真的要数据库迁移，这里面那么多复杂的逻辑关系，我折腾到啥时候是个头啊。有人说，Lucene啊，我想想也是，跟对方提了，
对方说可以啊，不过鉴于这个是第三方的，我们要提交到美国总部的IT部门那里审查。

我一听就放弃了，好家伙，大家都知道这种事情放到美国这种养胖子的国家审查，那到啥时候才能有眉目啊。我最关心的根本不是眼前这么点小活，而是可以进入他们的vendor list里去。

怎么办呢，我开始自己操刀，做法很简单，本来数据库有几十万条这样的数据。我做了个索引程序，先挨个读每一篇文章，单凡有新的汉字就在一张新的数据库表内添加一条记录，并且记录上该汉字所在文章的记录id号。如果已经有了，则在原来记录里添加，比如 “张” 对应记录号 1，15，16 现在第201篇有了，就是1,15,16,200。

但这样还是有点慢，我再把汉字转成UTF8 以UTF8 开头1位（不是标志位哦，别跟我抬杠。）在对这些汉字做个归类。

把他们搜索程序稍微改一下，提交即有汉字也有转成UTF8的数字码。另外他们提交文章（新增修改）的时候都会触发索引程序做次索引。

这里最麻烦的是修改，新增好办只要挨个读字，然后在已存字的记录集上添加就可以了。但是修改是真心麻烦，你想，一篇文章要是就修改几个字那还好办。但是如果是这里改一段那里改一句，你头都要大死了，你必须找出差异，在被修改掉的字的记录集合去掉当前记录号，然后在新增字上加上索引号。

光是比较差异我就能烦死了，我岁数一大把了，这么复杂的程序根本写不动，下面程序员就不要说了，我就不跟你们说现在的程序员水平有多糟糕了。于是我想出一个，干脆在修改的时候，就把原来的文章移出，移动到一张记录表，修改后的内容就按新增处理。

每天晚上再跑一个定时程序，一把统计出所有缺失的id（PK 自增），然后遍历我那个单字的数据表把缺失的记录直接从集合删除就可以了。很快。反正晚上以前，顶多就是有些在记录集合里id 找不到对应记录，找不到的就不显示，就完了。

因为被修改的文章会被移到另外一个数据源的一张表内（如果两次以上修改就只记录最近一次，），所以我跟客户说，你看我还提供你们新的功能，万一改错了，上次的记录还能追回来呢。

这个办法也就是初始建立的时候慢，到用户使用的时候就非常理想了。总共几天时间，就完工了。送到客户那里，对口的经理跟我说抱歉，首付款的po都还没来得及开呢。

新技术神马的，不会又怎样，又怎样？恩？当然这个做法为了提高效率我还送了2块固态硬盘.....不大点的成本，也算值了。