oracle的分页优化，真的坑啊

本来接到一个300万数据的表的优化任务，看了别人写的sql,找了半天发现where条件后面使用了to_char函数而且它还使用了sysdate来判断日期是否相等，也就是说有300万条数据，这个sysdate就要执行300万次，所以把sysdate换成常量，用java的时间格式处理好传递过来，然后感觉to_char执行效率太低，网上找个半天没有几个说正确的，有一个代替to_char的函数叫trunc的，试了下to_char只取出年份时用这个函数大概能优化0.2秒左右，至于网上说的sql全部大写，感觉连0.001秒都不能优化，所以基本无用。后来看了很多找到了oracle的函数索引，因为字段使用了函数后就放弃索引，所以必须使用函数索引，本来我都想直接新建几个字段，把所有时间转换成需要的字符串直接建立索引的，后来有了函数索引就连sysdate都不需要换成常量了，执行效率很高，就是不知道开销大不大，最后就到了使用rownum分页优化的问题了，普通的rowmun分页使用三层子查询，最里面一层把需要的字段查出来然后再根据rownum分页，可是最里面是数据的全查询，也就是整个表的查询，查询的字段多了自然就很慢了，所以改变方式，最里面使用rowid,因为rowid是唯一的，而且数据占用空间极其小，也可以使用主键id,基本都是一样的，因为主要是使用到它的唯一性，其实现在查出来比如说10条数据，和传统方式查询出来的区别只是传统方式查出具体字段，而现在也是查出这10条的rowid,然后外面套一层，把你具体字段查询，然后where条件后面写上rowid in 你的查询结果就可以了，公司内网没法传代码坑，网上这些rowid分页也有可以看下，这边只是讲一个比较坑的，就是in这个问题，本来我使用的是rowid分页方式，大概能优化1秒钟左右查询时间，可是给了测试后，测试使用的是oracle11版本，我也是醉了，11这个版本不知道为什么，我in语句里面只要加入查询语句就凉凉了，很恶心，当时以为是数据库高水平线太高导致，直接把表truncate了一下，结果还是坑，用普通方式分页就可以，所以只能放弃用in，也就是用两表联查，a.rowid =b.你的rowid定义的别名，哎，真的伤不起。老衲不想整java了。整了快两年了，感觉什么都没混出来，除了近视加深，腰疼加重，什么都没得到。我一直在想我适不适合java,就像今天这个问题，出了问题我都想砸电脑。整个java行业跟我想的不一样，我以为技术最重要，没想到吹牛逼更重要，呵呵，说不定哪天就离开这个行业啊