数据库delete不释放空间处理方法

最新推荐文章于 2025-06-30 10:55:06 发布

原创最新推荐文章于 2025-06-30 10:55:06 发布 · 1.8w 阅读

31 ·

CC 4.0 BY-SA版权

文章标签：

#delete #数据库 #释放空间

数据库专栏收录该内容

10 篇文章

订阅专栏

本文探讨了因频繁增删操作导致数据库表出现大量碎片的问题及解决方案。介绍了MySQL、Greenplum (gp)、GBase和Oracle数据库中如何通过优化表、回收垃圾、压缩表空间等手段释放磁盘空间并提升查询性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最近做项目遇到个问题，数据库实际有效数据才几万行，但是因为该表属于频繁变动的表，单节点实际已经超过30亿行，rowid一直在增加，直接导致表不可用。最后分析下来，是因为delete操作只是将数据标识位删除，并没有整理数据文件，因此在数据文件中留下了碎片，不释放其占用的空间。如果一张表，频繁被insert、delete，且删除的数据没有规律，那么数据就会出现大量的空洞，占用磁盘空间且影响查询性能。

经过网上搜索了解，目前delete删除数据库有两种情况：

1）当DELETE后面跟条件的时候，则就会出现删除数据后，数据表占用的空间大小不会变。

如：delete from table_name where 条件

2）不跟条件直接delete的时候，清除了数据，同时数据表的空间也会变为0。

如：delete from table_name

那么，针对这个问题，搜索整理了一些目前常见的数据库处理方法：

1）mysql：使用OPTIMIZE TABLE 指令对表进行优化。
命令语法：OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
最简单的：optimize table XXX;
OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。
注意，在OPTIMIZE TABLE运行过程中，MySQL会锁定表。因此，这个操作一定要在网站访问量较少的时间段进行。

在多数的设置中，根本不需要运行OPTIMIZE TABLE。即使对可变长度的行进行了大量的更新，也不需要经常运行，每周一次或每月一次只对特定的表运行即可。

2）、gp数据库：定期使用Vacuum analyze tablename 回收垃圾和收集统计信息。
该动作会消耗系统一定的资源，引起系统的IO上升，对有一定系统瓶颈来说容易造成堵塞，严重会把GP宕掉，造成数据库瞬断。vacuum只是简单的回收空间且令其可以再次使用，没有请求排它锁，仍旧可以对表读写。
但是在postgresql中VACUUM的效果并不明显，一般都可认为不回收空间，只有vacuum full才会。vacuum full执行更广泛的处理，包括跨块移动行，以便把表压缩至使用最少的磁盘块数目存储。相对vacuum要慢，而且会请求排它锁。
在日常维护中，需要对数据字典定期执行vacuum，可以每天在数据库空闲的时候进行。然后每隔一段较长时间(两三个月)对系统表执行一次vacuum full，这个操作需要停机，比较耗时，大表可能耗时几个小时。reindex:执行vacuum之后,最好对表上的索引进行重建。

3）、gbase数据库：使用alter table XXX shrink space释放空间。

4）、oracle数据库：

如：alter table XXX enable row movement;
alter table XXX shrink space
注意：shrink table只会针对assm（自动段空间管理）的表有用，否则会报： ORA-10635: Invalid segment or tablespace type。
alter table XXX enable row movement语句会造成引用表tablename_max的对象(如存储过程、包、视图等)变为无效。执行完成后，最好执行一下utlrp.sql来编译无效的对象。