這是因?yàn)閯h除操作后在數(shù)據(jù)文件中留下碎片所致。DELETE只是將數(shù)據(jù)標(biāo)識(shí)位刪除，并沒(méi)有整理數(shù)據(jù)文件，當(dāng)插入新數(shù)據(jù)后，會(huì)再次使用這些被置為刪除標(biāo)識(shí)的記錄空間。另外實(shí)際操作過(guò)程中還發(fā)現(xiàn)這個(gè)問(wèn)題還存在兩種情況。

（1）當(dāng)DELETE后面跟條件的時(shí)候，則就會(huì)出現(xiàn)這個(gè)問(wèn)題。如：

delete from table_name where 條件

刪除數(shù)據(jù)后，數(shù)據(jù)表占用的空間大小不會(huì)變。

（2）不跟條件直接delete的時(shí)候。如：

delete from table_name

清除了數(shù)據(jù)，同時(shí)數(shù)據(jù)表的空間也會(huì)變?yōu)?。

這就存在了一個(gè)問(wèn)題，在網(wǎng)站的實(shí)際運(yùn)行過(guò)程中。經(jīng)常會(huì)存在這樣的附帶條件刪除數(shù)據(jù)的操作行為。天長(zhǎng)日久，這不就在數(shù)據(jù)庫(kù)中浪費(fèi)了很多的空間嗎。這個(gè)時(shí)候我們?cè)撌褂?OPTIMIZE TABLE 指令對(duì)表進(jìn)行優(yōu)化了。

如何使用 OPTIMIZE 以及在什么時(shí)候該使用 OPTIMIZE 指令呢？

命令語(yǔ)法：OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

最簡(jiǎn)單的：optimize table phpernote_article;

如果您已經(jīng)刪除了表的一大部分，或者如果您已經(jīng)對(duì)含有可變長(zhǎng)度行的表（含有VARCHAR, BLOB或TEXT列的表）進(jìn)行了很多更改，則應(yīng)使用

OPTIMIZE TABLE。被刪除的記錄被保持在鏈接清單中，后續(xù)的INSERT操作會(huì)重新使用舊的記錄位置。您可以使用OPTIMIZE

TABLE來(lái)重新 利用未使用的空間，并整理數(shù)據(jù)文件的碎片。

在多數(shù)的設(shè)置中，您根本不需要運(yùn)行OPTIMIZE TABLE。即使您對(duì)可變長(zhǎng)度的行進(jìn)行了大量的更新，您也不需要經(jīng)常運(yùn)行，每周一次或每月一次即可，只對(duì)特定的表運(yùn)行。

OPTIMIZE TABLE只對(duì)MyISAM, BDB和InnoDB表起作用。

注意，在OPTIMIZE TABLE運(yùn)行過(guò)程中，MySQL會(huì)鎖定表。因此，這個(gè)操作一定要在網(wǎng)站訪問(wèn)量較少的時(shí)間段進(jìn)行。

TRUNCATE

其語(yǔ)法結(jié)構(gòu)為：

TRUNCATE [TABLE] tbl_name

這里簡(jiǎn)單的給出個(gè)示例，

我想刪除 friends 表中所有的記錄，可以使用如下語(yǔ)句：

truncate table friends;

delete的效果有點(diǎn)像將mysql表中所有記錄一條一條刪除到刪完，而truncate相當(dāng)于保留mysql表的結(jié)構(gòu)，重新創(chuàng)建了這個(gè)表，所有的狀態(tài)都相當(dāng)于新表,這樣空間就減下來(lái)了。

好了，當(dāng)然對(duì)于我們網(wǎng)站不可能使用truncate table來(lái)清除了，因這樣之后所有數(shù)據(jù)都丟失了，這樣肯定是不合理的清除了，我們必須使用delete來(lái)刪除，然后再來(lái)修復(fù)優(yōu)化表了哦。