一个开发实例的有关问题（快照相关）
一个开发实例的问题（快照相关）
现有一个总表table1，只有一个主键mobile，行数6500万，列数40列。
现今要用java开发一个数据平台，实现的效果是，将总表中的数据进行分类统计以图表的形式显示出来，比如说按地域统计，各地区占比多少，统计结果；按照年龄统计，各个年龄层的人数多少；按手机运营商分类，各个运营商的占比，诸如此类的统计工作。可以一个星期统计一次（如星期五的晚上12点），无需实时更新
运用到的的SQL语句多是以“select count(1) from table1 where 条件1 and 条件2” 类型的。公司的一个搞开发的以前说，由于源表table1数据量较多，在查询的时候会导致查询的速度较慢，且table1中的一些列的数据在统计的时候是用不到的，于是建议创建几个快照，将要查询的数据复制到该表中。
创建快照的语句如下：
但是如上（刷新时间上有改动）创建几个快照之后（创建过程中还因为表空间不足，增添了新的数据文件），数据库变得特别慢，CPU占用100%，查看刷新情况，发现有几个job的this date与next date 一样，且都比SYSDATE的时间早，也就说 ，快照的刷新卡住了。现今我的打算是先把几个快照删除，看看数据库会不会好一些。想问大家，关于这种实际的案例，有没有好的解决方法，无论是关于快照卡住的原因、或者是应对这种案例更适合的解决方案实现平台需要的功能
------解决思路----------------------
由于你的表数据量比较大，因此统计的时候尽量一次遍历把需要统计的结果都查询出来，不要每个条件都遍历一遍全表
查询时使用类似下面的语法
------解决思路----------------------
另外你的数据是不是只有插入操作，不存在更新的问题？
这样的话你可以将上一次的统计结果存储起来
在下次统计时，只需要统计两次统计之间的这段时间的数据
然后再累加上上次统计的结果，就能得到最终的结果
------解决思路----------------------
说白了，大数据量的统计尽量不要整体统计，最好能用增量统计的方式进行统计
------解决思路----------------------
建议，LZ 把你的 MV 做成手工刷新，周五晚上 12 点，这几个 MV 按顺序刷，不要一下子跑多个。
------解决思路----------------------
看起来这个需求和物化视图没什么关系
如果在同一个库里，不要用物化视图了
一周同步一次，说明实时性要求不高。与其让物化视图来定时刷新，不如直接对源表进行操作，优化处理过程。然后将统计步骤写到存储过程中，定时调用存储过程来生成结果
现有一个总表table1，只有一个主键mobile，行数6500万，列数40列。
现今要用java开发一个数据平台，实现的效果是，将总表中的数据进行分类统计以图表的形式显示出来，比如说按地域统计，各地区占比多少，统计结果；按照年龄统计，各个年龄层的人数多少；按手机运营商分类，各个运营商的占比，诸如此类的统计工作。可以一个星期统计一次（如星期五的晚上12点），无需实时更新
运用到的的SQL语句多是以“select count(1) from table1 where 条件1 and 条件2” 类型的。公司的一个搞开发的以前说，由于源表table1数据量较多，在查询的时候会导致查询的速度较慢，且table1中的一些列的数据在统计的时候是用不到的，于是建议创建几个快照，将要查询的数据复制到该表中。
创建快照的语句如下：
CREATE MATERIALIZED VIEW SN_YDPRODUCT
REFRESH COMPLETE ON DEMAND
START WITH TO_DATE('27-12-2014 02:00:59', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE + 7
AS
SELECT mobile,sex,age,os,cellbrand,SOURCE
FROM base
但是如上（刷新时间上有改动）创建几个快照之后（创建过程中还因为表空间不足，增添了新的数据文件），数据库变得特别慢，CPU占用100%，查看刷新情况，发现有几个job的this date与next date 一样，且都比SYSDATE的时间早，也就说 ，快照的刷新卡住了。现今我的打算是先把几个快照删除，看看数据库会不会好一些。想问大家，关于这种实际的案例，有没有好的解决方法，无论是关于快照卡住的原因、或者是应对这种案例更适合的解决方案实现平台需要的功能
------解决思路----------------------
由于你的表数据量比较大，因此统计的时候尽量一次遍历把需要统计的结果都查询出来，不要每个条件都遍历一遍全表
查询时使用类似下面的语法
select
sum(case when 条件1 then 1 end) 条件1的记录数,
sum(case when 条件2 then 1 end) 条件2的记录数,
……
from T
------解决思路----------------------
另外你的数据是不是只有插入操作，不存在更新的问题？
这样的话你可以将上一次的统计结果存储起来
在下次统计时，只需要统计两次统计之间的这段时间的数据
然后再累加上上次统计的结果，就能得到最终的结果
------解决思路----------------------
说白了，大数据量的统计尽量不要整体统计，最好能用增量统计的方式进行统计
------解决思路----------------------
建议，LZ 把你的 MV 做成手工刷新，周五晚上 12 点，这几个 MV 按顺序刷，不要一下子跑多个。
------解决思路----------------------
看起来这个需求和物化视图没什么关系
如果在同一个库里，不要用物化视图了
一周同步一次，说明实时性要求不高。与其让物化视图来定时刷新，不如直接对源表进行操作，优化处理过程。然后将统计步骤写到存储过程中，定时调用存储过程来生成结果