日期:2014-05-16  浏览次数:21159 次

查询百万级数据太慢的问题请教。
我有一个数据目前接近四百万的表,(数据库oracle)
1:这个表有几个重要字段如下:IMEI , APP_ID ,STATE ,(其他字段省略);
2:这个表每新增一条数据,都必须判断IMEI和APP_ID是否已经同时存在过,根据是否已经存在过,来更新STATE 字段;
3:每天新增数据有好几万,所以要判断好几万次;

我做过的优化:IMEI和APP_ID都已经建过索引,表也重构过。
备注:IMEI这个字段数据变化较大,APP_ID数据合计就是几千个,变化不大;

现在问题是,逻辑是很简单,但是由于数据量太大,每次判断都要10来秒,效率很低,请问是否有更好的设计方法,或者是优化的方法。


------最佳解决方案--------------------
你索引怎么建的?是建个联合索引,(app_id,imei), app_id放前面吗?
------其他解决方案--------------------
1、试一试用merge into 能不能提高性能
2、如果业务允许可以试试,先将每天新增的数据直接放入一张中间表,在一个统一的时间 或者 利用job 不定期的 从A表merge into 到你的400W表中。
------其他解决方案--------------------
引用:
我有一个数据目前接近四百万的表,(数据库oracle)
1:这个表有几个重要字段如下:IMEI , APP_ID ,STATE ,(其他字段省略);
2:这个表每新增一条数据,都必须判断IMEI和APP_ID是否已经同时存在过,根据是否已经存在过,来更新STATE 字段;
3:每天新增数据有好几万,所以要判断好几万次;

我做过的优化:IMEI和APP_ID都已经建过索引,表也重构过。
……

这是可以提高效率,但是现在问题不在插入,最大问题是查询,查询很慢,我认为oracle处理几百万数据不应该这么慢的,肯定有什么办法可以提高查询的效率的。
------其他解决方案--------------------
引用:
你索引怎么建的?是建个联合索引,(app_id,imei), app_id放前面吗?

不是联合索引,两个都是独立建的,查询的时候是app_id放前面。
------其他解决方案--------------------
400万用户数据不多 要是有几千万了 可以考虑分表 500万一张什么的
然后把经常需要更新的字段分离出去 新建一张表  主键 对应这些经常更新的字段。
------其他解决方案--------------------
执行计划看没看过?

------其他解决方案--------------------
null