(1)省下的数据量如果不大,那么可以考虑建立一张临时表,将需要保留的数据临时灌过去,然后truncate该表,然后再把数据灌回来。也可以考虑drop表,然后另外一张表改名,不过这样可能会有很多的后续 *** 作,比如索引的建立等等,因此一般不用drop *** 作。
(2)上亿的数据,应该有分区吧,如果可能的话,按照分区truncate,这样也可以。
(3)实在不能truncate,只能delete那么建议找个字段循环删除提交,每次不能太多,最好保持在5万以下(根据实际情况具体判断),毕竟delete是最消耗资源的dml语句。
(4)如果可能的话,不要同一时间 *** 作,分批 *** 作,这样能减少一部分数据库负载压力(特别是undo)。
(5)一定要闲时 *** 作,因为delete消耗资源比较多,会使数据库变慢。
1、首先明确一点,如果每条数据需要一秒的时间,假如是一亿条数据至少需要2年左右,意味着你两年都不能使用这个数据库,在现实生活中,你认为可能这样做吗?
2、解决这类问题的最好办法就是:时间换空间,例如:最早的新浪微薄的用户登陆日志就这样实现的,他的登陆日志并不是在用户每次登陆后进行更新的,而当用户量少的时间段进行数据的更新 *** 作,或则每次用户登陆的时候多执行一条更新的语句,不过这样做,缺少实时性。
3、正所谓:“鱼和熊掌二者不可得兼”,我认为并没有空间和时间可以得到完全平衡的方法,只是看你更在意空间还是时间问题。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)