在用sqlite設計表時,每個表都有乙個自己的整形id值作為主鍵,其實可以不指定這麼乙個id值,sqlite內部本來就會為每個表加上乙個 rowid,這個rowid可以當成乙個隱含的字段使用,但是由sqlite引擎來維護的,在3.0以前rowid是32位的整數,3.0以後是 64位的整數,為什麼不直接使用這個內部的rowid作為每個表的id主鍵呢。
相關的文件在這裡:?
用指定integer primary key autoincrement 和不指定自增長欄位用rowid有什麼區別:
使用自增長字段為主鍵有不少問題,比如維護或是在大型分布應用中主鍵衝突的解決等。在一些大型分布應用中主鍵一般選用guid,這可以有效的避免主鍵衝突,減少對主鍵維護的工程。當然,對於中小型的應用,自增長欄位的好處更多一些,簡單、快速。
sqlite中,乙個自增長字段定義為integer primary key autoincrement,那麼在插入乙個新資料時,只需要將這個欄位的值指定為null,即可由引擎自動設定其值,引擎會設定為最大的rowid+1。當然,也可以設定為非null的數字來自己指定這個值,但這樣就必須自己小心,不要引起衝突。當這個rowid的值大於所能表達的最大值 9223372036854775807 (3.0及以後版本的rowid最大值)後,rowid的新值會這個最大數之前隨機找乙個沒被使用了的值。所以在rowid達到最大值前,rowid的值是嚴格單調增加的。
integer primary key autoincrement 自增長欄位的演算法與rowid稍微有些不同。
第一,在達到最大值後,rowid會找已被刪除的字段對應的rowid作為新值,而自增長欄位則會丟出乙個sqlite_full的錯誤。
第二,自增長欄位在增加新值時,是找乙個從沒被使用過的rowid作為新值,而rowid則是找最大已存在的rowid+1。這裡對應用的影響會比較大,尤其是一些對id值有依賴的元記錄,只適合使用自增長欄位而不能用rowid。
比如,我們設計乙個元記錄表:
drop table test;
create table test (
[tkid] integer primary key autoincrement, -- 設定主鍵
[tktype] int default 0,
[tableid] varchar (50),
[createdate] datetime default (datetime('now', 'localtime')) -- 時間
);第三,使用自增長字段,引擎會自動產生乙個sqlite_sequence表,用於記錄每個表的自增長欄位的已使用的最大值,使用者可以看到,並可以用使用 update、delete和insert操作,但不建議這麼使用,這會讓引擎混亂。如果使用rowid,也會有這麼乙個內部表,使用者可以維護rowid 值,但看不到。
這麼看來,如果直接使用rowid來代替自增加字段,根據兩者的細微的差別,需要注意是否與自己的應用衝突,如果沒有衝突,那麼用rowid會更快一點。
sqlite中建立自增字段:
簡單的回答:乙個宣告為 integer primary key 的字段將自動增加。
從 sqlite 的 2.3.4 版本開始,如果你將乙個表中的乙個字段宣告為 integer primary key,那麼無論你何時向該錶的該字段插入乙個 null 值,這個 null 值將自動被更換為比表中該字段所有行的最大值大 1 的整數;如果表為空,那麼將被更換為 1。
乙個新的api函式 sqlite3_last_insert_rowid() 返回最近的插入操作的整形鍵.
sqlite3自增key設定 建立自增字段
在用sqlite設計表時,每個表都有乙個自己的整形id值作為主鍵,其實可以不指定這麼乙個id值,sqlite內部本來就會為每個表加上乙個 rowid,這個rowid可以當成乙個隱含的字段使用,但是由sqlite引擎來維護的,在3.0以前rowid是32位的整數,3.0以後是 64位的整數,為什麼不直...
sqlite3自增key設定 建立自增字段
在用sqlite設計表時,每個表都有乙個自己的整形id值作為主鍵,其實可以不指定這麼乙個id值,sqlite內部本來就會為每個表加上乙個 rowid,這個rowid可以當成乙個隱含的字段使用,但是由sqlite引擎來維護的,在3.0以前rowid是32位的整數,3.0以後是 64位的整數,為什麼不直...
SQLite3中自增主鍵相關知識總結
一 sqlite清空表並將自增列歸零 sql標準中有truncate table語句,用來清空表的所有內容。但sqlite不支援這個語句。在sqlite中直接使用 delete from tablename 就可以了。對於大多數dbms來說,用delete不如用truncate 速度快,因為trun...