无知害死人

最近我接连犯了两个比较重大的失误，非常的低级，低级到我无法原谅我自己。

一个是数据删除操作，因为采用全新的框架，不是很熟悉流程，所以在删除前进行了一些断点测试，查看参数调用情况，一直跟踪到核心代码，最后一次测试的时候，字段名没有传入，事实上这完全是我的故意，因为我想知道，字段名没有传入到底框架会给出什么样的错误提示，写了一个这样的SQL语句

DELETE FROM post WHERE ’123456′  AND ‘ 456789′

这是执行这个语句花了一份多钟，我还以为发生错误了，因为是周六晚上调试的，周日早上睡大觉，运营的同学打电话给我们系统管理员，很多用户反映日志丢失了，我猜想我完了，就昨天我发布了新的功能，因为周末太闲。在mysql 的bin log中查到一条类似如上的SQL语句，转念一想，这个WHERE根本就没用，没有字段的where查询，后面都是true，相当于：

DELETE FROM post WHERE  true  AND true

执行了之后的结果是，整个表被清空！还好我们采用的是分库分表的策略，我删除的不过几百个表中的一个，丢掉近一万个用户数据，最后劳烦我们万能的系统管理员花开同学 从备份中给找回来了。这其中得到神仙的协助， 虽然没有任何人批评或指责我，我永远记得这个教训。

第二个是关键词匹配系统，主要用来查找包含关键字的垃圾文章（spam）。这个是写的第一个完全不需要模板的程序，说白了，就是命令行运行的东西，但还算不上真正意义上CLI程序，关键字存在一个表的一个字段中，以回车分割每个字符，这个是通过另外的一套WEB界面输入的，我提取关键词的方法是explode(‘\n’, $str),结果运行了好几十次，查到的匹配文章少的可怜，今天晚上（2009-03-10）老魏告诉我，每天的spam远远大于我查找的数量，我查到的几乎可以忽略不计，这下我汗颜了，我一直以为是我们所有的用户都非常纯洁，所以才只有那么几个spam，原来是我程序出问题了，之前我都是直接增加一个常用的词进行测试的，比如“的”，查找非常准确，所以我深信我的程序没有问题，最后在刚哥（我刚到Bus时被指定的师傅，一位做了8年开发的牛人）的排查下,原来是windows下的换行和Linux下的换行根本就不是一回事，windows下是以 \r ，Linux下是\n,在将每个关键字trim一下之后,搜20个表就搜了近千篇垃圾文章。

我应该好好检讨我自己，无知有时候真的会害死人，因为不知道，所以死了也不知道怎么死了！