很小的表做很简单的dml操作却长时间跑不出来，可能是这个问题导致的！

  这是一个前年我在生产数据库发布脚本时遇到的问题 ，因涉及到公司管理制度问题，脚本需由甲方运维老师执行。这个脚本我在开发环境（DEV）、功能测试（FT）、系统集成测试（SIT）、性能评估测试（PET）、预生产环境（PP）都执行过，且很快就执行完了，也就零点几秒。

这位运维老师执行了快半小时还没执行完。我因为没法直接操作，只能在旁边看着，指导应该怎么查，后来我突然想到是不是统计信息失真导致SQL执行计划出了问题。于是让他查一下，结果，果然！我不知道具体什么原因这个环境没配置自动收集统计信息，反正查到这个问题后，我再查一些关键业务大表，发现也都没有统计信息。这就坑了，一个生产环境居然不定期自动收集统计信息，再怎么优化也不能为了这点性能耗费，导致更高的性能耗费啊！

找到问题后，我让运维老师立即停止执行，再执行如下语句：

ANALYZE TABLE 表名 COMPUTE STATISTICS;

再次执行，也是零点几秒就完成了。汗！

还好我当时在申请数据库用户权限时额外申请了ANALYZE权限。我分析原因是，这张表最近做了大规模插入、删除操作，导致旧的执行计划失真了，数据量变化了，再按照旧的执行计划软解析执行，才出现的问题。

如果你遇到类似的问题，不妨先查看一下USER_TABLES、ALL_TABLES、DBA_TABLES其中之一，根据需求和权限管控具体问题具体分析。

SELECT TABLE_NAME,NUM_ROWS FROM USER_TABLES WHERE TABLE_NAME = '表名';

如果NUM_ROWS为NULL，很有可能就是这张表自建立以来一直没收集过统计信息。当然，也存在特例，毕竟USER_TABLES这种系统视图也是延迟更新的。