查询百万级数据太慢的问题请教。
我有一个数据目前接近四百万的表，（数据库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