〈求助--在线等〉不用添加Index解决全表扫描的问题（Tuning优化问题）

Question

        ... ...        sbHql.append("select \n");
        sbHql.append("    max(fldhcmn.eda) \n");
        sbHql.append("from \n");
        sbHql.append(PpfsLdHistoryHead.class.getName());
        sbHql.append(" as fldhh, \n");
        sbHql.append(PpfsLdHistoryCmn.class.getName());
        sbHql.append(" as fldhcmn \n");
        sbHql.append("where \n");
        sbHql.append("    fldhh.comp_id.koyuno = fldhcmn.comp_id.koyuno \n");
        sbHql.append("    and fldhh.comp_id.zogenkaisu = fldhcmn.comp_id.zogenkaisu \n");
        sbHql.append("    and fldhcmn.kaishacd = :kaishacd \n");
        sbHql.append("    and fldhcmn.oya = :oya \n");
        sbHql.append("    and fldhh.historyjotaikbn = :historyjotaikbn\n");        ... ...

Answer 1

 *刚才没编辑完，不小心碰了回车。上外网速度太慢，回复不及时对不起各位了。
 *这个表很大，只有一个Index,由  kaishacd strkbn oya eda 组成，但这四个项目在具体应用的
 *时候大部分时间都是Null.
 *
 *现在马上就要Release，如果追加Index的话，Installer就要重做，上头为了掩饰设计错误，
 *交给我们做优化，脑袋都想炸了。

Answer 2

不看执行计划，我是怎么知道他是table access full的呢？

Answer 3

说实话,我还是觉得你问题描述的不清楚......
你直接把你程序设计的一段代码拿上来让大家帮你看,不是说这样不行,只是很别扭
你把SQL整理下发上来,带上你的执行计划,问题不是更容易解决吗!

Answer 4

这段理解的也不是很清楚......追加index只是库会变,难道installer是包含装库的信息?这个installer可是够大的......把DBA的活都给干了......
另外SQL本身有问题的话,几率比较小,很大的优化都是在库这边,通过执行计划发现问题,只改SQL就能达到很大优化的话,只能说开发人员SQL写的太差了......

Answer 5

 SELECT MAX(fldhcmn.eda)
   FROM table1 AS fldhh, table1 AS fldhcmn
  WHERE fldhh.comp_id.koyuno = fldhcmn.comp_id.koyuno
AND fldhh.comp_id.zogenkaisu = fldhcmn.comp_id.zogenkaisu
AND fldhcmn.kaishacd = :kaishacd
AND fldhcmn.oya = :oya
AND fldhh.historyjotaikbn = :historyjotaikbn;这段sql看起来怎么这么怪？难道comp_id是自定义类型的？
查询条件对表的一个实例fldhcmn是在kaishacd, oya,上的，应该能用上一次INDEX SKIP SCAN。当然楼主说这几个列大部分时候是NULL，所以索引检索的效果不见得好。
查询条件对表的一个实例fldhh是在historyjotaikbn上，通过comp_id.koyuno和comp_id.zogenkaisu关联，这里有没有任何索引可供检索，全表扫描是不可避免的。
如果表的数据量很大，性能必然很差。除了添加合理的索引，我看不到其它的办法。