oracle上亿表海量数据进行大批量数据删除有什么好的解决方案

以下纯属个人意见，请根据实际情况判断

(1)省下的数据量如果不大，那么可以考虑建立一张临时表，将需要保留的数据临时灌过去，然后truncate该表，然后再把数据灌回来。也可以考虑drop表，然后另外一张表改名，不过这样可能会有很多的后续 *** 作，比如索引的建立等等，因此一般不用drop *** 作。

（2）上亿的数据，应该有分区吧，如果可能的话，按照分区truncate，这样也可以。

（3）实在不能truncate，只能delete那么建议找个字段循环删除提交，每次不能太多，最好保持在5万以下（根据实际情况具体判断），毕竟delete是最消耗资源的dml语句。

（4）如果可能的话，不要同一时间 *** 作，分批 *** 作，这样能减少一部分数据库负载压力（特别是undo）。

（5）一定要闲时 *** 作，因为delete消耗资源比较多，会使数据库变慢。

加索引

使用分区表

对于历史不用数据，导出数据库备份；

对于历史不常用数据，使用低速存储设备进行存储；将高速设备用来存储当前数据。

根据项目实践，发现警博士分布式集群数据库系统（SCSDB），具有类似Hadoop的分布式存储与支持并行计算的功能特点，又具有类似传统关系型数据库的某些 功能特点，保留了二维表的逻辑存储模式，数据按行、列组织，支持多表关联，非常适合于海量结构化数据的存储和大数据分析。

如果简单讲数据库换成oracle，那就谈不上设计了

如果设计不合理，你换成oracle也解决不了问题，

1、日增量为一亿，为什么不分表呢？按用途、类型等分一下，降低单表数据量

2、当前使用的数据，和历史数据分表，提高当前数据的查询效率

3、日增量为一个亿，都是关键数据和最新数据吗，请考虑将insert改为update

4、最后一步，加物理索引和普通索引

解决办法

针对一

避免大表 *** 作 所有的 *** 作均可以按省或者时间分开 这样无论从时间或者地域维度 基本上可以将大表拆成 张以上的小表 *** 作 甚至更多 然后再对结果进行合并 应该可以避免上述问题

针对二

无解决方案 只是建议将我们的数据库也单独分到一组磁盘上去 不要跟系统竞争

针对三

及时删除无用的临时数据 保障数据库空间 同时也可以做上空间监控 一旦数据文件空间发生增长时 给DBA一个预警邮件 我们收到邮件后可以立即做相应处理

针对四

日志文件目前已经涨得较大 我们执行一下截断日志的动作 将日志文件的空间使用保持在一个较低水平

lishixinzhi/Article/program/SQLServer/201311/22405

对于第一个问题，设计一个schema->(messageID，likedCount)，记录每条微博的点赞数。messageID是微博的编号，likedCount是该微博的点赞人数。但是这里有两个问题需要解决，第一是并发，第二是数据量。

每条微博都有可能有很多人同时点赞，为了保证点赞人数精确就需要保证likedCount是原子 *** 作，这个可以由应用程序来实现，也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话)，但是我觉得为了性能考虑，也可以不用实现原子 *** 作，具体原因就不展开了。

每天都上亿可能更多的微博内容产生，这样就会有上亿个新的(messageID，likedCount)生成，这样的数据量是比较大的，单机数据库比较难提供高效的服务，所以需要采取sharding的功能(有时候也叫分表分库)，可能根据messageID把这些schema分散到十个或者更多的shards上(据说，sina微博有600个节点，如何三个节点组成一个shard，就有200个shards)，这样每个shard处理的请求就只有原来的十分之一，从而就能提高服务的性能。

关于点赞人列表的设计，一般来说，可能想到的schema是(messageID，userID)，但是这样的设计有一个小问题，就是有些大发的微博可能会得到几十万的点赞，这样就会产生几十万个条数据，这样数据有点多，读取起来可能也慢。所以可以用这样一个schema(messageID，partID，userIDs)，让一个messageID对于多个userID，同时比对应太多的userID，所以加入一个新的partID，一个part存1000个userID，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

要看你一条有多大。

MySQL数据库的最大有效表尺寸通常是由 *** 作系统对文件大小的限制决定的，

而不是由MySQL内部限制决定的。所以，如果你的 *** 作系统支持单个文件超过1T，

应该没有什么问题。

大小跟你系统所支持的最大单个文件大小有关

首先分析为什么慢：1 6个子查询，每个子查询都需要建立中间表；2，每个子查询都在做 group by, 重复；3 CASE WHEN 用不了索引，需要扫描所有列； 优化：CASE WHEN 逻辑合并，6个子查询合并为1个查询，做1次 group by，做 join，

以上就是关于oracle上亿表海量数据进行大批量数据删除有什么好的解决方案全部的内容，包括:oracle上亿表海量数据进行大批量数据删除有什么好的解决方案、数据库问题，已有100亿数据,如何提高查询速度、我有个项目，数据表特多，单表数据量超亿条，要实现多表联查分析，底层采用什么数据库，才能实时出结果等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！