MySQL和Oracle中的delete,truncate對比

在MySQL和Oracle中的delete,truncate還是存在著一些差別，明白了這些差別可能對於處理問題，理解問題會有一些幫助。

我們來簡單透過一些測試來說明。我們建立兩個表test_del,test_tru來對比delete,truncate的操作。我們有一個臨時表t_fund_info大概有幾百萬的資料量。

建立test_del

> create table test_del select *from t_fund_info;
Query OK, 1998067 rows affected (34.77 sec)
Records: 1998067  Duplicates: 0  Warnings: 0

建立test_tru

> create table test_tru select *from t_fund_info;
Query OK, 1998067 rows affected (35.21 sec)
Records: 1998067  Duplicates: 0  Warnings: 0這個時候我們來檢視對應的檔案，在MySQL中通用的方式，對於每個表會對應單獨的資料檔案和配置檔案。
我們可以看到存在4個新的檔案，大小都是一樣的。

-rw-rw---- 1 mysql mysql       9545 Nov 22 09:52 test_del.frm
-rw-rw---- 1 mysql mysql       9545 Nov 22 09:53 test_tru.frm
-rw-rw---- 1 mysql mysql  390070272 Nov 22 09:53 test_del.ibd
-rw-rw---- 1 mysql mysql  390070272 Nov 22 09:54 test_tru.ibd我們開始測試兩者的不同。

> delete from test_del;
> truncate table test_tru;這個時候再次檢視目錄下的檔案情況，可以赫然看到test_tru的資料檔案徹底釋放了,而delete之後的檔案大小還是保持原樣。

-rw-rw---- 1 mysql mysql       9545 Nov 22 09:52 test_del.frm
-rw-rw---- 1 mysql mysql       9545 Nov 22 09:53 test_tru.frm
-rw-rw---- 1 mysql mysql  390070272 Nov 22 09:55 test_del.ibd
-rw-rw---- 1 mysql mysql      98304 Nov 22 09:55 test_tru.ibd那麼delete的表怎麼釋放哪些空間呢，可以考慮重置儲存引擎。

> alter table test_del engine=innodb;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0整個過程非常快，而操作之後檢視檔案，大小已經收縮了。

-rw-rw---- 1 mysql mysql       9545 Nov 22 09:53 test_tru.frm
-rw-rw---- 1 mysql mysql      98304 Nov 22 09:55 test_tru.ibd
-rw-rw---- 1 mysql mysql       9545 Nov 22 09:58 test_del.frm
-rw-rw---- 1 mysql mysql      98304 Nov 22 09:58 test_del.ibd這裡需要明白一點，就是修改儲存引擎的操作，還是和裡面的資料有關，在上面的這個場景中，這是一個較為特殊的例子。我們drop表test_del,然後重建一次看看。

> drop table test_del;
Query OK, 0 rows affected (0.01 sec)
> create table test_del select *from t_fund_info;
 Query OK, 1998067 rows affected (33.82 sec)
Records: 1998067  Duplicates: 0  Warnings: 0這個時候我們來看看存在大量資料的情況下，修改儲存引擎的情況。

可以看到操作的時間還是有著天壤之別

>  alter table test_del engine=innodb;
Query OK, 1998067 rows affected (28.07 sec)
Records: 1998067  Duplicates: 0  Warnings: 0為什麼要慢了很多呢，這是因為這個操作的底層操作就是複製資料。MySQL只是幫你做好了這些事情而已，可以看到在操作的過程中會建立一個臨時表。
rw-rw---- 1 mysql mysql       9545 Nov 22 09:53 test_tru.frm
-rw-rw---- 1 mysql mysql      98304 Nov 22 09:55 test_tru.ibd
-rw-rw---- 1 mysql mysql       9545 Nov 22 10:01 test_del.frm
-rw-rw---- 1 mysql mysql  390070272 Nov 22 10:02 test_del.ibd
-rw-rw---- 1 mysql mysql       9545 Nov 22 10:02 #sql-2931_463ab4.frm
-rw-rw---- 1 mysql mysql  276824064 Nov 22 10:03 #sql-2931_463ab4.ibddelete和truncate還是有一定的適用場景，此外在MySQL中還有一種使用方式就蠻有特色了，那就是選擇性的刪除，比如刪除test_del中id排序的前n條資料，可以在delete裡面使用order by limit的方式。

比如：

> delete from test_del order by id desc limit 2;
Query OK, 2 rows affected (3.56 sec)此外，MySQL和Oracle中還有一個較大的差別是，MySQL中的表資料檔案是完全複用的，而在Oracle中有多種方式，比如append,reuse等，這個本身和設計也有關係。

比如在MySQL中我們delete一個表的資料，然後重新插入，那麼這個空間是完全複用的。原有的檔案幾乎不會有所變化。

而truncate的操作在MySQL是一個很快的操作，資料轉瞬即逝，在Oracle中有一些差別，可能這些資料還有恢復的可能。

比如我們在Oracle端建立一個表空間，建立兩個表test_del,test_tru;

建立表空間
create tablespace test_data datafile '/U01/app/oracle/oradata/newtest2/test_data.dbf' size 10M autoextend on;
建立表test_del,test_tru
create table test_del tablespace test_data as select *from all_objects;
create table test_tru tablespace test_data as select *from all_objec

收集統計資訊
exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'TEST_DEL');
exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'TEST_TRU');

這個時候我們來測試一下兩者的差別。

這裡的差別在於，如果我們delete了資料之後，表test_del已經沒有資料，但是查詢的時候還是會全表掃描，掃描的資料塊和清理前基本是一樣的,而且代價還會更高一些。

SQL> delete from test_del;
68314 rows deleted.
select *from test_tru;

而truncate操作在Oracle,MySQL都是一個極快的過程，在Oracle中不會直接抹去資料，資料還是依舊存在，在一定的條件下觸發才會回收。

我們使用dbms_rowid來解析一下

SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid) as file#,dbms_rowid.ROWID_BLOCK_NUMBER(rowid) as block#,dbms_rowid.ROWID_ROW_NUMBER(rowid) as row#,a.object_id from test.test_tru a where rownum<2;
     FILE#     BLOCK#       ROW#  OBJECT_ID
---------- ---------- ---------- ----------
        11       1155          0      47837

然後對這個資料塊做一個dump.

alter system dump datafile 11 block 1155;    
truncate前的資料塊的一些資料。       

st: CR md: NULL fpin: 'kdswh11: kdst_fetch' tch: 2
  cr: [scn: 0x2c.d3775902],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x2c.d3775902],[sfl: 0x0],[lc: 0x2c.d3775456]
  flags: only_sequential_access
Block dump from disk:
buffer tsn: 9 rdba: 0x02c00483 (11/1155)
scn: 0x002c.d3775977 seq: 0x01 flg: 0x06 tail: 0x59770601
frmt: 0x02 chkval: 0x4141 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007F73BA551A00 to 0x00007F73BA553A00
7F73BA551A00 0000A206 02C00483 D3775977 0601002C  [........wYw.,...]
7F73BA551A10 00004141 00000001 000160F2 D377544F  [AA.......`..OTw.]
7F73BA551A20 0000002C 00320003 02C00480 0000FFFF  [,.....2.........]

頭部的一些資訊：bdba: 0x02c00483
data_block_dump,data header at 0x7f73ba551a7c
===============
tsiz: 0x1f80
hsiz: 0xa8
pbl: 0x7f73ba551a7c
     76543210truncate之後的資料如下:
  st: CR md: NULL fpin: 'kdswh11: kdst_fetch' tch: 2
  cr: [scn: 0x2c.d3775902],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x2c.d3775902],[sfl: 0x0],[lc: 0x2c.d3775456]
  flags: only_sequential_access
Block dump from disk:
buffer tsn: 9 rdba: 0x02c00483 (11/1155)
scn: 0x002c.d3775aa3 seq: 0x01 flg: 0x06 tail: 0x5aa30601
frmt: 0x02 chkval: 0xc285 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007F59FF1ABA00 to 0x00007F59FF1ADA00
7F59FF1ABA00 0000A206 02C00483 D3775AA3 0601002C  [.........Zw.,...]
7F59FF1ABA10 0000C285 00000001 000160F2 D3775A9E  [.........`...Zw.]
7F59FF1ABA20 0000002C 00320003 02C00480 0000FFFF  [,.....2.........]頭部的一些資訊如下，可以看到地址已經發生了改變，比如hsiz,pbl

bdba: 0x02c00483
data_block_dump,data header at 0x7f59ff1aba7c
===============
tsiz: 0x1f80
hsiz: 0x9a
pbl: 0x7f59ff1aba7c
     76543210
   在MySQL中可以很飄逸的使用limit，在Oracle中換種寫法，類似MySQL的語法：

> delete from test_del order by id desc limit 2;

在Oracle中可能得這麼些了，不考慮哪些分析函式的用法

delete from test_del where rowid in (select rowid from (select rowid from test_del order by id desc) where rownum<=2);

兩者對比結合起來還是會發現有不少有意思的小地方需要注意。

地方