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

      最近做项目遇到个问题，数据库实际有效数据才几万行，但是因为该表属于频繁变动的表，单节点实际已经超过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来编译无效的对象。