亿级别数据优化的问题！！！，请大家参与讨论，寻求解决方案
各位大牛小牛，大家好！
兄弟目前遇到难题一个，关于一个大表的问题
现描述如下：
1、项目数据2亿3千万条，单表，目前按月分区，每月600万左右
2.目前的焦点在于该表上一个视图需要对该表group by然后在和自身join，商业环境所限，没办法，呵呵，这个视图被多次调用，所以造成数据库压力的主要瓶颈所在

目前发现的问题有几点：
1.使用分区吧，发现微软这个分区有点意思，如果分区分的太细的话，比如按周，index scan很小了，但是有很大的nested loop代价，因为分区切换；分区设的少吧，发现索引代价大，超过100个分区性能急剧下降
2.采用提示吧，发现他也不行，提示在传到视图时不起作用
3.把索引字段加上限制时间吧，发现到了视图里面因为groupby的缘故，代价仍然很大
请问各位牛人，有什么高深意见，有亿级数据处理经验的老兄们登高出彩了！！



------解决方案--------------------
如果是05：可用分区表(分区函数)/分区索引实现。。
如果是2000，可把数据库作为历史数据库调用
------解决方案--------------------
项目数据2亿3千万条?

个人认为,如果不对数据分表,分库,同时建立相应的主键和索引,其任何查询没有多大意义.
当然,执行语句后,去看个A片,拍个婆子回来后数据也许会查出来.
------解决方案--------------------
没有必要死抠数据库方面的优化,完全可以从业务需求和实现逻辑方面进行改进,例如可以和业务部门讨论这种实现代价太大的需求是否可以进行调整,可否增加一层或多层中间表,不再每次查询都访问不再变化的原始数据表,或者改成用数据仓库用维度来实现,等等.
------解决方案--------------------
英国佬不干，那就没有办法了。
对亿级的表进行group by,那就是要求绕月飞行再回到地球啦，从当前的数据库结构里，再什么优化，也不会得到什么明显的好处，因为任务过程就是这么多。
适当增加表，用来存储group by的结果，在生成数据的时候同时填充，是最好的结果。