iLeichun

曾经遇到的一个例子就是这样，开发人员为了要求每次对一个表做操作的时候都使用索引，于是在代码中强行加入了Hint约束SQL的执行计划，它的样子大概是这样：

Select /*+ index(t1 ind_t1) */ col1,col2 from t1 where col1>...... and col1<...... 猜测他们在系统上线之前测试的阶段，发现这条SQL选择索引比全表扫描效率高得多，为了保证以后执行计划能够始终选择索引，他们在代码中的SQL里加入了这个Hint。

系统上线后，没有出现过问题，直到有一天用户抱怨查询非常慢，我从数据库里得到了用户端发出的SQL，才知道这个SQL在代码里加入了Hint。问题是，为什么之前操作都没有问题呢？我登录这个数据库，查看了一下这个表的信息，惊奇地发现，这个表每天仍然定时在做分析操作，这是一个奇怪的现象，人为地对表进行定时分析，却不允许数据库来选择执行计划，这显然是不合理的事情。但这种现象在开发人员当中又是比较普遍的，大家了解一些数据库的技术，却无法将这些知识整合起来运用，系统设计及开发阶段，没有DBA参与进来，直到系统进入运行维护阶段，才有DBA来充当救火队员的角色，这在当前中国软件开发中是一个很普遍的现象。

接着说这个案例。这是一个Oracle 10gr2的数据库，CBO（基于成本的优化器）的技术已经比较成熟，所以此时应该选择由Oracle数据库来决定SQL的执行计划。我分别执行了这条原始SQL和去掉了Hint的SQL，并获得了各自的执行计划，执行计划显示出，去掉Hint的SQL选择了全表扫描（Full Table Scan），执行中扫过的数据块远远小于通过索引访问数据的SQL，于是原因找到了。

可是为什么之前没有出现过这个问题？我对比了一下最近的数据和之前的数据，发现近期的数据在创建索引的列上的列值重复率要远远高于从前，因此Oracle在选择索引之后，比以前读取了更多的索引块和数据块，造成了大量的I/O操作。

因此，对于高版本的数据库（10g以上），我们还是应该让数据库自己根据表、索引的统计分析信息来决定SQL的执行计划，因为表中的数据是会变化的，这种人为的强行干预，必然会在某个时候出现问题。