iT邦幫忙

0

資料庫與AutoIncrement欄位的問題

cfc 2008-11-03 19:41:576114 瀏覽

在這邊我想請教各位先進一個問題,我想以MySQL來舉例好了
一般來說我習慣建立一個欄位叫id,預設是INT(11),且是自動增加的欄位當主鍵
在MySQL中,INT佔用4Bytes,TINYINT佔用
也就是說就算id只有1~10,這每筆資料光是id這欄位就每個佔了4Bytes是嗎?
有時候某些應用程式不需要用到INT可以用到TINYINT的,卻因為被刪除掉的id不能重新新增(因為沒有紀錄)回去,所以那個欄位一直空著。
如果說今天我確定使用者人數不會超過TINYINT的範圍,卻因為資料可能有人刪除後又新增,這樣id數會一直累加累加,直到TINYINT裝不下為止,這樣的話,我又得把欄位改為INT
然後同樣的事情又發生在INT上,然後不得不改為BIGINT
我真的覺得這樣很浪費容量(畢竟BIGINT佔用8 Bytes...)
所以我的想法是用另外一個表儲存被刪除掉的id值,然後當資料要新增時從中挑選一個id來新增,重複使用空間,然後再刪除表內那個id
不知道這樣可不可行?

fillano iT邦超人 1 級 ‧ 2008-11-04 16:12:39 檢舉
如果要這樣做,那你要自己管理concurrent的問題,例如racing。為了能應付這些問題,你需要做table lock。這樣除了增加程式撰寫的難度,還會影響到一些效能。

2 個回答

16
brianc
iT邦研究生 1 級 ‧ 2008-11-03 22:59:43
最佳解答

INT加上unsigned可以到4,294,967,295,要用到完的機會應該非常低,至於耗用的空間以目前硬碟的容量來說也還好,不建議為了這個理由增加程式設計的複雜度。另外為了維持資料的完整性,最好使用status或is_delete欄位來註記刪除的記錄,避免直接刪除

6
pantc328
iT邦研究生 1 級 ‧ 2008-11-04 08:24:52

這種東西沒什麼好考量的,現在的HD,Memory都是上G的.4Byte跟8Byte根本沒差別.
而就整個Record,ID是很重要的,但在記錄所占的空間比率卻不大.

我要發表回答

立即登入回答