(1)省下的数据量如果不大,那么可以考虑建立一张临时表,将需要保留的数据临时灌过去,然后truncate该表,然后再把数据灌回来。也可以考虑drop表,然后另外一张表改名,不过这样可能会有很多的后续 *** 作,比如索引的建立等等,因此一般不用drop *** 作。
(2)上亿的数据,应该有分区吧,如果可能的话,按照分区truncate,这样也可以。
(3)实在不能truncate,只能delete那么建议找个字段循环删除提交,每次不能太多,最好保持在5万以下(根据实际情况具体判断),毕竟delete是最消耗资源的dml语句。
(4)如果可能的话,不要同一时间 *** 作,分批 *** 作,这样能减少一部分数据库负载压力(特别是undo)。
(5)一定要闲时 *** 作,因为delete消耗资源比较多,会使数据库变慢。
问题分析:这种问题是由于服务器的数据库文件或者日志太大造成的,那么我们清理下日志或者收缩数据库就可以了。解决方法:一
第一种解决方案,不限制数据库文件大小,当然,这是在您的服务器空间足够的情况下
二
第二种解决方案,直接清理数据库日志文件
我们打开数据库,然后选择分离数据库,找到日志文件并删除,然后附加,会自动产生
一个初始的很小的日志文件
三
第三种收缩数据库日志文件,设置数据库文件或者日志文件收缩到一定大小就可以。
以上各种解决方案,可以根据不同情况选择不同方案,为防止对数据库 *** 作不熟悉, ***
作失误,修改前请先备份好数据库。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)