监控发现数据库服务器I/O比较高，查询发现一条占用I/O相对很高的SQL。

delete from IVL_DEBUG.MED_BRD_PGM_VOD;

这条SQL每十分钟执行一次，提交给开发人员，既然是全表删除，让他改成truncate，不要用delete，但开发人员很强势，老子一次就删2万多条数据，怎么会占你I/O。

在下只好低头哈腰的给他解释了半天，delete是不会回收空间的，咱们数据库的表空间很充足，数据文件还自动扩展，你用delete删除数据之后，这部分空间虽然被置成可用状态了，但表空间充足的情况下，一般并不会被使用，这样这张表就会越删越大，你虽然只删除2万多条数据，但是这SQL要走全表扫描。

也不知道他是真不懂还是装糊涂，只好给他看数据了，我查了下表大小，将近12GB。

SQL> select bytes/1024/1024/1024 from dba_segments where segment_name='MED_BRD_PGM_VOD';

BYTES/1024/1024/1024
--------------------
          11.7763672

查询发现，这张表的确就6万多条数据。

SQL> select count(*) from IVL_DEBUG.MED_BRD_PGM_VOD;

  COUNT(*)
----------
     26516

查询这张表上并没有索引。

SQL> select index_name from dba_indexes where table_name='MED_BRD_PGM_VOD';

no rows selected

通过move命令清理这张表的碎片。

SQL> alter table IVL_DEBUG.MED_BRD_PGM_VOD move;

Table altered.

再次查询，这张表的大小变成正常大小，仅有4MB。

SQL> select bytes/1024/1024 from dba_segments where segment_name='MED_BRD_PGM_VOD';

BYTES/1024/1024
---------------
              4

给他看了这些数据，然后根据数据和他解释，这张表，2万多条的记录，正常就不到4MB，就算是4MB，你delete一次，删除了4MB的数据，但是这4MB的空间不会被利用，比如下次又进来4MB数据，这张表就变成了8MB，你再用delete删除这张表的所有数据，虽然你只删2万多条，4MB的数据，但是数据库由于全表扫描，要读8MB的磁盘，下次就是12MB，表会越来越大。就像之前那表已经12GB了，你一次虽然只删除2万多条数据，但是数据库要读12GB的磁盘，就占用了大量的I/O。

可能是被我的诚意所感动，程序员大哥终于答应修改程序代码了。

由于这个程序使用的业务用户和表的OWNER并不是同一个用户，程序配置的是TRUNCATE，但是ORACLE不同用户直接是不能直接TRUNCATE操作的，程序就自动把truncate转换成delete了，就导致了这个问题，最终的解决方案是在表的OWNER用户下创建一个存储过程来truncate那张表，然后业务用户去调用这个存储过程进行TRUNCATE操作。

本文固定链接: https://www.dbdream.com.cn/2018/03/oracle%e6%95%b0%e6%8d%ae%e5%ba%93%e9%a2%91%e7%b9%81delete%e5%af%bc%e8%87%b4%e8%a1%a8%e7%a2%8e%e7%89%87%e6%a1%88%e4%be%8b/ | 信春哥，系统稳，闭眼上线不回滚！