这个案例说来也很简单。话说我们公司旧版本的mediation系统每天都需要从各个network element（NE）的服务器上采集CDR，采集程序一般都是用expect写的，其实就是ftp到对方的机器上拷贝文件过来。NE里的CDR一般不会轻易做house keep，这就要求我们的采集程序自己能够辨认哪些文件已经下载过，否则的话，全部下载过来处理，客户就要被重复计费了。因此，在本地数据库中，有一个表专门保存已经下载过的文件名字，采集程序ftp登录之后，首先会使用ls命令看看目标路径里都有些什么文件，然后逐一以这些文件名为查询条件，到本地数据库的表中查一下，有没有这个文件的下载记录，如果有，再查下一个文件名，如果没有，把这个文件名保存到缓冲区，全部查询完成之后，再根据缓冲区中的文件列表逐一下载该文件，下载一个就往数据表插入一条该文件的下载记录。
看上去天衣无缝吧。谁知道某一天，问题来了。大家知道，ftp是有超时设置的，而采集程序ftp登录之后，逐一查找比较文件有没有曾经下载过，也是需要时间的，如果文件数量比较多，查找时间大于ftp的超时设置，这样下载就永远不会成功了。每次经过千辛万苦的查找之后，都会弹出令人沮丧的消息：
[25.05 10:34:05] Step 001 LOG SQL> ftp> bin
[25.05 10:34:05] Step 001 LOG Not connected.
[25.05 10:34:05] Step 001 INFO FTP_CLIENT mo_bg-CDR_2010-05-25T000932.log.gz start copying
[25.05 10:34:05] Step 001 LOG get CDR_2010-05-25T000932.log.gz /usr/users/nmds/amd/arm/input/raw/mo_bg1/tmp-mo_bg-CDR_2010-05-25T000932.log.gz-tmp
[25.05 10:34:05] Step 001 LOG Not connected.
还好日志上有时间戳，记录了采集程序从登录成功到真正开始传输，足足等待了超过5分钟，说明当中的查找比较过程太慢了。翻看源程序，发现执行的SQL是：
SELECT SYSID from smt_ftp_files where SYSID ='$SYSID' and FILENAME = '$FILENAME';
不必多说，这个查询应该在filename或者sysid字段上有索引，才会快。进入oracle数据库，看看其索引，竟然没有，于是新建一条，重新运行，读取要下载的文件列表只要十几秒，不到2分钟，整个下载过程都完成了。
SQL> select index_name from all_indexes where table_name='SMT_FTP_FILES';
no rows selected
SQL> create index idx_filename on smt_ftp_files(filename);
Index created.
SQL> select index_name from all_indexes where table_name='SMT_FTP_FILES';
INDEX_NAME
------------------------------
IDX_FILENAME