關於sqlite遇到問題時的一點思考

本文主要介紹sqlite資料庫遇到的一些問題以及解決的思路，接下來我們一一介紹。

rowid和integer主鍵及自增屬性

大多數情況下，sqlite3的表都有乙個rowid(也叫oid,_rowid_),這是乙個64位的整數，並作為sqlite儲存結構b樹的主鍵。因此使用rowid查詢會比以其他設定的主鍵查詢，速度會非常快。

在做插入操作的時候，對於rowid的值通常情況下不要去指定，讓系統自己去決定該去何值。因為sqlite會通過sqlite_sequence來追蹤表的rowid取值情況。而且sqlite定義了rowid的取值演算法：在未超出rowid的範圍內，待插入記錄的rowid總是表中存在過的的rowid最大值+1。比如依次插入5條記錄，此時最後一條記錄的rowid是5，如果把這條記錄刪除再插入新記錄，此時新紀錄的rowid是6。而當rowid達到所能表達的最大值時，這時如果有新紀錄要插入，系統就會隨機從之前的沒有使用過的正整數中隨機取乙個作為rowid(就是之前刪除過的)。若沒有未使用的正整數並且你沒有在插入的時候制定rowid為某乙個負數的話，系統就會丟擲sqlite_full的錯誤。

如果在建立表的時候設定了主鍵，並且設定主鍵的那列是integer(不是int,short integer等等)，並且主鍵沒有設定降序時，這時的主鍵是rowid的別名，換言之,主鍵和rowid沒有區別。如果我們再設定主鍵autoincrement屬性時。和rowid又有什麼區別呢?區別只是在於此時主鍵的取值是乙個未使用過的rowid值，而這個rowid值系統會保證其是單調增長的,通常情況下就是表中存在過的rowid最大值+1。這裡所說的通常情況下是因為有這樣一種情況：當插入操作由於表約束而失敗的時候，本來要賦值的rowid，有可能不會在下次插入操作中使用，此時主鍵的取值就是表中存在過的rowid最大值+2。

因此對於使用者id是整數的表，是單獨設主鍵去維護還是直接使用rowid作為主鍵，就取決於各自的業務邏輯關係了。在這種情況下,通常不使用rowid的主鍵特性。

union all

假設有兩張表：

create table a (username varchar(50), created datetime);   
create table b (nickname varchar(50), userid integer, added datetime);

表a和表b之間沒有任何關係,唯一有聯絡的就是有一列屬性都是datetime。而boss就需要將a和b的所有值取出並按時間排序。

乍一看不知道咋解決，因為兩張表剛好沒有關係啊.後來才意識到可以用union，比如：

select null as col1, username as col2,created as col3 from a

union all

select nickname as col1, userid as col2,added as col3 from b

order by col3;

然後根據某一列值是否為空來生成不同的物件。

思考：1.遇到這個問題後,首先想到的是join，但表又是沒有關係的，所以陷入了死胡同，跳出這個思維，從sql本身出發，問題解決。

2.從軟體開發的角度，對於已經進行了一半的開發，如果有新的需求，對於已有的軟體架構，資料庫結構都會是乙個挑戰。但這樣的變化往往是不可避免，尤其是在小公司，用scrum開發的環境下。遇到這樣的問題只能希望架構師依靠自己的檢驗，設計出易於擴充套件的架構。

取出某一段資料

sqlite取出某一段資料是用limit，比如要取出第6-20條記錄，只需：

select * from tablename limit 5,15.

關於sqlite的問題總結就先介紹到這裡，我們還會在以後的文章中接著介紹，感興趣的朋友可以繼續關注。

關於sqlite遇到問題時的一點思考

安裝gym時遇到問題

建立Redis集群時遇到問題（一）

建立Redis集群時遇到問題（二）

關於sqlite遇到問題時的一點思考

安裝gym時遇到問題

建立Redis集群時遇到問題（一）

建立Redis集群時遇到問題（二）

相關推薦