(6)SQLite線程安全嗎？

線程是魔鬼（Threads are evil）。 避免使用它們。

SQLite 是線程安全的。由于很多用戶會忽略我們在上一段中給出的建議， 我們做出了這種讓步。但是，為了達到線程安全，SQLite在編譯時必須將 SQLITE_THREADSAFE 預處理宏置為1。在Windows和Linux上，已編譯的好的二進制發(fā)行版中都是這樣設置的。如果不確定你所使用的庫是否是線程安全的，可以調(diào)用 sqlite3_threadsafe() 接口找出。

在 3.3.1 版本之前，一個 sqlite3 結構只能被用于調(diào)用 sqlite3_open 創(chuàng)建的同一線程。你不能在一個線程中打開數(shù)據(jù)庫，然后將數(shù)據(jù)庫句柄傳遞給另外一個進程使用。這主要是由于在好多通用的線程實現(xiàn)（如RedHat9）中的限制引起的（是Bug嗎？）。特別的，在有問題的系統(tǒng)上，一個進程創(chuàng)建的 fcntl() 鎖無法被其它線程清除或修改。 所以，由于 SQLite 大量使用 fcntl() 鎖做并發(fā)控制，如果你在不同的線程間移動數(shù)據(jù)庫連接，就可能會出現(xiàn)嚴重的問題。

在3.3.1版本上，關于在線程間移動數(shù)據(jù)庫連接的限制變得寬松了。 在它及以后的版本中，只要連接沒有持有 fcntl() 鎖，在線程間移動句柄是安全的。 如果沒有未決的事務，并且所有的語句都已執(zhí)行完畢， 你就可以安全的假定不再持有任何鎖。

在UNIX中，在執(zhí)行 fork() 系統(tǒng)調(diào)用時不應攜帶已打開的數(shù)據(jù)庫進入子進程。 那樣做將會有問題。


--------------------------------------------------------------------------------

(7)在SQLite數(shù)據(jù)庫中如何列出所有的表和索引？

如果你運行 sqlite3 命令行來訪問你的數(shù)據(jù)庫，可以鍵入 “.tables”來獲得所有表的列表?；蛘撸憧梢暂斎?nbsp;“.schema” 來看整個數(shù)據(jù)庫模式，包括所有的表的索引。 輸入這些命令，后面跟一個LIKE模式匹配可以限制顯示的表。

在一個 C/C++ 程序中（或者腳本語言使用 Tcl/Ruby/Perl/Python 等） 你可以在一個特殊的名叫 SQLITE_MASTER 上執(zhí)行一個SELECT查詢以獲得所有 表的索引。每一個 SQLite 數(shù)據(jù)庫都有一個叫 SQLITE_MASTER 的表，它定義數(shù)據(jù)庫的模式。 SQLITE_MASTER 表看起來如下：

CREATE TABLE sqlite_master (
  type TEXT,
  name TEXT,
  tbl_name TEXT,
  rootpage INTEGER,
  sql TEXT
);

對于表來說，type 字段永遠是 'table'，name 字段永遠是表的名字。所以，要獲得數(shù)據(jù)庫中所有表的列表， 使用下列SELECT語句：

SELECT name FROM sqlite_master
WHERE type='table'
ORDER BY name;

對于索引，type 等于 'index', name 則是索引的名字，tbl_name 是該索引所屬的表的名字。 不管是表還是索引，sql 字段是原先用 CREATE TABLE 或 CREATE INDEX 語句創(chuàng)建它們時的命令文本。對于自動創(chuàng)建的索引（用來實現(xiàn) PRIMARY KEY 或 UNIQUE 約束），sql字段為NULL。

SQLITE_MASTER 表是只讀的。不能對它使用 UPDATE、INSERT 或 DELETE。 它會被 CREATE TABLE、CREATE INDEX、DROP TABLE 和 DROP INDEX 命令自動更新。

臨時表不會出現(xiàn)在 SQLITE_MASTER 表中。臨時表及其索引和觸發(fā)器存放在另外一個叫 SQLITE_TEMP_MASTER 的表中。SQLITE_TEMP_MASTER 跟 SQLITE_MASTER 差不多，但它只是對于創(chuàng)建那些臨時表的應用可見。如果要獲得所有表的列表， 不管是永久的還是臨時的，可以使用類似下面的命令：

SELECT name FROM
   (SELECT * FROM sqlite_master UNION ALL
    SELECT * FROM sqlite_temp_master)
WHERE type='table'
ORDER BY name


--------------------------------------------------------------------------------

(8) SQLite數(shù)據(jù)庫有已知的大小限制嗎？

在 Windows 和 Unix 下，版本 2.7.4的 SQLite 可以達到 2的41次方字節(jié) (2T 字節(jié))。老版本的為 2的31 次方字節(jié)(2G 字節(jié))。
SQLite 版本 2.8 限制一個記錄的容量為 1M。SQLite 版本 3.0 則對單個記錄容量沒有限制。
表名、索引表名、視圖名、觸發(fā)器名和字段名沒有長度限制。但 SQL 函數(shù)的名稱 (由 sqlite3_create_function() API 函數(shù)創(chuàng)建) 不得超過 255 個字符。

對有關SQLite限制的詳細討論，見 limits.html 。


--------------------------------------------------------------------------------

(9) 在SQLite中，VARCHAR字段最長是多少？

SQLite 不強制 VARCHAR 的長度。 你可以在 SQLITE 中聲明一個 VARCHAR(10)，SQLite還是可以很高興地允許你放入500個字符。 并且這500個字符是原封不動的，它永遠不會被截斷。


--------------------------------------------------------------------------------

(10) SQLite支持二進制大對象嗎？

SQLite 3.0 及以后版本允許你在任何列中存儲 BLOB 數(shù)據(jù)。 即使該列被聲明為其它類型也可以。


--------------------------------------------------------------------------------

(11) 在SQLite中，如何在一個表上添加或刪除一列？

SQLite 有有限地 ALTER TABLE 支持。你可以使用它來在表的末尾增加一列，可更改表的名稱。 如果需要對表結構做更復雜的改變，則必須重新建表。 重建時可以先將已存在的數(shù)據(jù)放到一個臨時表中，刪除原表， 創(chuàng)建新表，然后將數(shù)據(jù)從臨時表中復制回來。

如，假設有一個 t1 表，其中有 "a", "b", "c" 三列， 如果要刪除列 c ，以下過程描述如何做:

BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;


--------------------------------------------------------------------------------

(12) 我在數(shù)據(jù)庫中刪除了很多數(shù)據(jù)，但數(shù)據(jù)庫文件沒有變小，是Bug嗎？

不是。當你從SQLite數(shù)據(jù)庫中刪除數(shù)據(jù)時， 未用的磁盤空間將會加入一個內(nèi)部的“自由列表”中。 當你下次插入數(shù)據(jù)時，這部分空間可以重用。磁盤空間不會丟失， 但也不會返還給操作系統(tǒng)。

如果刪除了大量數(shù)據(jù)，而又想縮小數(shù)據(jù)庫文件占用的空間，執(zhí)行 VACUUM 命令。 VACUUM 將會從頭重新組織數(shù)據(jù)庫。這將會使用數(shù)據(jù)庫有一個空的“自由鏈表”， 數(shù)據(jù)庫文件也會最小。但要注意的是，VACUUM 的執(zhí)行會需要一些時間（在SQLite開發(fā)時，在Linux上，大約每M字節(jié)需要半秒種），并且，執(zhí)行過程中需要原數(shù)據(jù)庫文件至多兩倍的臨時磁盤空間。

對于 SQLite 3.1版本，一個 auto-vacumm 模式可以替代 VACUUM 命令。 可以使用 auto_vacuum pragma 打開。


--------------------------------------------------------------------------------

(13) 我可以在商業(yè)產(chǎn)品中使用SQLite而不需支付許可費用嗎？

是的。SQLite 在 public domain。 對代碼的任何部分沒有任何所有權聲明。你可以使用它做任何事。


--------------------------------------------------------------------------------

(14) 如何在字符串中使用單引號(')？

SQL 標準規(guī)定，在字符串中，單引號需要使用逃逸字符，即在一行中使用兩個單引號。在這方面 SQL 用起來類似 Pascal 語言。 SQLite 尊循標準。如：

    INSERT INTO xyz VALUES('5 O''clock');


--------------------------------------------------------------------------------

(15) SQLITE_SCHEMA error是什么錯誤？為什么會出現(xiàn)該錯誤？

當一個準備好的（prepared）SQL語句不再有效或者無法執(zhí)行時， 將返回一個 SQLITE_SCHEMA 錯誤。發(fā)生該錯誤時，SQL語句必須使用 sqlite3_prepare() API來重新編譯. 在 SQLite 3 中, 一個 SQLITE_SCHEMA 錯誤只會發(fā)生在用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 執(zhí)行 SQL 時。而不會發(fā)生在使用 sqlite3_exec()時。 在版本2中不是這樣。

準備好的語句失效的最通常原因是：在語句準備好后， 數(shù)據(jù)庫的模式又被修改了。另外的原因會發(fā)生在：

數(shù)據(jù)庫離線：DETACHed.
數(shù)據(jù)庫被 VACUUMed
一個用戶存儲過程定義被刪除或改變。
一個 collation 序列定義被刪除或改變。
認證函數(shù)被改變。
在所有情況下，解決方法是重新編譯并執(zhí)行該SQL語句。 因為一個已準備好的語句可以由于其它進程改變數(shù)據(jù)庫模式而失效， 所有使用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 的代碼都應準備處理 SQLITE_SCHEMA 錯誤。下面給出一個例子：

    int rc;
    sqlite3_stmt *pStmt;
    char zSql[] = "SELECT .....";

    do {
      /* Compile the statement from SQL. Assume success. */
      sqlite3_prepare(pDb, zSql, -1, &pStmt, 0);

      while( SQLITE_ROW==sqlite3_step(pStmt) ){
        /* Do something with the row of available data */
      }

      /* Finalize the statement. If an SQLITE_SCHEMA error has
      ** occured, then the above call to sqlite3_step() will have
      ** returned SQLITE_ERROR. sqlite3_finalize() will return
      ** SQLITE_SCHEMA. In this case the loop will execute again.
      */
      rc = sqlite3_finalize(pStmt);
    } while( rc==SQLITE_SCHEMA );

  

--------------------------------------------------------------------------------

(16) 為什么 ROUND(9.95,1) 返回 9.9 而不是 10.0？ 9.95不應該圓整 (四舍五入）嗎？

SQLite 使用二進制算術，在二進制中， 無法用有限的二進制位數(shù)表示 9.95 。使用 64-bit IEEE 浮點 （SQLite就是使用這個）最接近 9.95 的二進制表示是 9.949999999999999289457264239899814128875732421875。所在，當你輸入 9.95 時，SQLite實際上以為是上面的數(shù)字， 在四舍五入時會舍去。

這種問題在使用二進制浮點數(shù)的任何時候都會出現(xiàn)。 通常的規(guī)則是記住很多有限的十進制小數(shù)都沒有一個對應的二進制表示。 所以，它們只能使用最接近的二進制數(shù)。它們通常非常接近， 但也會有些微小的不同，有些時候也會導致你所期望的不同的結果。

最新評論