3亿数据快速检索实现

我敢说你们公司没有一个正规的DBA.
看看server的配置.建立数据加加index.看看跑多久.
你说了在PLSQL上跑的时间我只能说你很没经验.DB是oracle吗?
上线后的东西是放在什么环境?APP SERVER是什么?有没有会出现HTTP握手的情况?你有没有想到上线后网络连接的问题?这些都会再加慢速度.
第一条是DB的隔离级别.每个connection设置一下就好了.会牵扯到dead lock.
每个DB的隔离级别含义都不一样.
第二个业务不懂.不知什么意思.
其实.基本上你这种情况很少会出现,应该从需求上出发.避免大数据让用户区查.比如限制它查询的范围.半年前的数据就不显示之类的.你要搞清楚需求,看看用户到底想看到的是什么.不要老板说了什么你就傻去做.基本上正规来说.一些大数据的表每一年都会做一次备份.做成view去select.
分表的解决方案没考虑到数据量继续增大以后怎么维护和备份.按照什么切?这个标准以后再增加维护起来就痛苦了.

完了，难道是我表达问题很多人都没看懂！

这种方案之前我们都讨论过，你们是怎么实现复杂查询的？

的确是的.你要把整个需求说清楚.你这个问题最好是从需求入手.
不要你就是说放一个表里面3亿条数据.怎么查的快.我觉得做这种事情是没意义的.
你们是根据什么去查的?单表还是多表?
查找的时候根据业务需求的不同会有很多小技巧的.你写的太模糊了.
比如说.by user去查的话. user在你那个3亿表中肯定不是一对一的吧?
你那个3亿表放的你只说了放手机号码.结构是怎样的?是by 什么去查的?
SQL的写法上有很多技巧的.比如小表链接大表.index的加法? 多看看excution plan.
肯定有很多废资料.要定期清除的.
你不说清楚需求,这块去哪入手呢?
出发点是怎么避免大数据的查询.
你们这个玩意当初是谁设计的?
设计的时候考虑到了吗?

看来看去还是觉得抛出异常的爱的建议不错。
其次，我觉得你的瓶颈不仅仅在数据库更新上。

数据库更新其实很好解决.
不知道你们有没有DataExchange的概念.
可以create一个新表去Insert.
等到晚上的时候再update回主表.

最大难点在于规则方案少....
检索慢...不过5分钟应该足够用了


一秒100TPS一宿也update不了多少.

这个就简单了.首先你是用当天insert的哪张表去update所以不是3亿数据都UPDATE.
小表join大表去update.
OK.不过我基本上都不用update.因为update是一条一条去做的.
没关系.还是很easy.
基本的做法是根据PK去delete然后再 addbatch insert.
delete的时候用exist .这些都是小技巧了.
技巧很多很多. 比如insert的时候先drop index 全部insert以后再create index.
问题是楼主的需求他自己估计都搞不懂.
PS:我本来是做web开发的,现在主要负责DataExchange的部分.

没有Index，你说怎么查的-_-!

好办法...