(1) 如何建立自动增长字段?
简短回答：声明为 INTEGER PRIMARY KEY 的列将会自动增长。
长一点的答案： 如果你声明表的一列为 INTEGER PRIMARY KEY，那么， 每当你在该列上插入一NULL值时， NULL自动被转换为一个比该列中最大值大1的一个整数，如果表是空的， 将会是1。 (如果是最大可能的主键9223372036854775807，那个，将键值将是随机未使用的数。） 如，有下列表：
CREATE TABLE t1(
a INTEGER PRIMARY KEY,
b INTEGER
);
在该表上，下列语句
INSERT INTO t1 VALUES(NULL,123);
在逻辑上等价于：
INSERT INTO t1 VALUES((SELECT max(a) FROM t1)+1,123);
有一个新的API叫做 sqlite3_last_insert_rowid()， 它将返回最近插入的整数值。
注意该整数会比表中该列上的插入之前的最大值大1。该键值在当前的表中是唯一的。但有可能与已从表中删除的值重叠。要想建立在整个表的生命周期中唯一的键值，需要在 INTEGER PRIMARY KEY 上增加AUTOINCREMENT声明。那么，新的键值将会比该表中曾能存在过的最大值大1。如果最大可能的整数值在数据表中曾经存在过，INSERT将会失败，并返回SQLITE_FULL错误代码。
--------------------------------------------------------------------------------
(2)SQLite3支持何种数据类型？
NULL
INTEGER
REAL
TEXT
BLOB
但实际上，sqlite3也接受如下的数据类型：
smallint 16 位元的整数。
interger 32 位元的整数。
decimal(p,s) p 精确值和 s 大小的十进位整数，精确值p是指全部有几个数(digits)大小值，s是指小数点後有几位数。如果没有特别指定，则系统会设为 p=5; s=0 。
float 32位元的实数。
double 64位元的实数。
char(n) n 长度的字串，n不能超过 254。
varchar(n) 长度不固定且其最大长度为 n 的字串，n不能超过 4000。
graphic(n) 和 char(n) 一样，不过其单位是两个字元 double-bytes， n不能超过127。这个形态是为了支援两个字元长度的字体，例如中文字。
vargraphic(n) 可变长度且其最大长度为 n 的双字元字串，n不能超过 2000。
date 包含了 年份、月份、日期。
time 包含了 小时、分钟、秒。
timestamp 包含了 年、月、日、时、分、秒、千分之一秒。
参见 http://www.sqlite.org/datatype3.html.
--------------------------------------------------------------------------------
(3)SQLite允许向一个integer型字段中插入字符串！
这是一个特性，而不是一个bug。SQLite不强制数据类型约束。任何数据都可以插入任何列。你可以向一个整型列中插入任意长度的字符串，向布尔型列中插入浮点数，或者向字符型列中插入日期型值。 在 CREATE TABLE 中所指定的数据类型不会限制在该列中插入任何数据。任何列均可接受任意长度的字符串（只有一种情况除外：标志为INTEGER PRIMARY KEY的列只能存储64位整数，当向这种列中插数据除整数以外的数据时，将会产生错误。
但SQLite确实使用声明的列类型来指示你所期望的格式。所以，例如你向一个整型列中插入字符串时，SQLite会试图将该字符串转换成一个整数。如果可以转换，它将插入该整数；否则，将插入字符串。这种特性有时被称为 类型或列亲和性(type or column affinity).
--------------------------------------------------------------------------------
(4)为什么SQLite不允许在同一个表不同的两行上使用0和0.0作主键？
主键必须是数值类型，将主键改为TEXT型将不起作用。
每一行必须有一个唯一的主键。对于一个数值型列， SQLite认为 '0' 和 '0.0' 是相同的，因为他们在作为整数比较时是相等的(参见上一问题)。 所以，这样值就不唯一了。
--------------------------------------------------------------------------------
(5)多个应用程序或一个应用程序的多个实例可以同时访问同一个数据库文件吗？
多个进程可同时打开同一个数据库。多个进程可以同时进行SELECT 操作，但在任一时刻，只能有一个进程对数据库进行更改。
SQLite使用读、写锁控制对数据库的访问。（在Win95/98/ME等不支持读、写锁的系统下，使用一个概率性的模拟来代替。）但使用时要注意：如果数据库文件存放于一个NFS文件系统上，这种锁机制可能不能正常工作。这是因为 fcntl() 文件锁在很多NFS上没有正确的实现。在可能有多个进程同时访问数据库的时候，应该避免将数据库文件放到NFS上。在Windows上，Microsoft的文档中说：如果使用 FAT 文件系统而没有运行 share.exe 守护进程，那么锁可能是不能正常使用的。那些在Windows上有很多经验的人告诉我：对于网络文件，文件锁的实现有好多Bug，是靠不住的。如果他们说的是对的，那么在两台或多台Windows机器间共享数据库可能会引起不期望的问题。
我们意识到，没有其它嵌入式的 SQL 数据库引擎能象 SQLite 这样处理如此多的并发。SQLite允许多个进程同时打开一个数据库，同时读一个数据库。当有任何进程想要写时，它必须在更新过程中锁住数据库文件。但那通常只是几毫秒的时间。其它进程只需等待写进程干完活结束。典型地，其它嵌入式的SQL数据库引擎同时只允许一个进程连接到数据库。
但是，Client/Server数据库引擎（如 PostgreSQL, MySQL, 或 Oracle）通常支持更高级别的并发，并且允许多个进程同时写同一个数据库。这种机制在Client/Server结构的数据库上是可能的，因为总是有一个单一的服务器进程很好地控制、协调对数据库的访问。如果你的应用程序需要很多的并发，那么你应该考虑使用一个Client/Server 结构的数据库。但经验表明，很多应用程序需要的并发，往往比其设计者所想象的少得多。
当SQLite试图访问一个被其它进程锁住的文件时，缺省的行为是返回 SQLITE_BUSY。 可以在C代码中使用 sqlite3_busy_handler() 或 sqlite3_busy_timeout() API 函数调整这一行为。
---------------------------------------------------------------------------
(6)SQLite线程安全吗？
线程是魔鬼（Threads are evil）。 避免使用它们。
SQLite 是线程安全的。由于很多用户会忽略我们在上一段中给出的建议，我们做出了这种让步。但是，为了达到线程安全，SQLite在编译时必须将 SQLITE_THREADSAFE 预处理宏置为1。在Windows和Linux上，已编译的好的二进制发行版中都是这样设置的。如果不确定你所使用的库是否是线程安全的，可以调用 sqlite3_threadsafe() 接口找出。
在 3.3.1 版本之前，一个 sqlite3 结构只能被用于调用 sqlite3_open 创建的同一线程。你不能在一个线程中打开数据库，然后将数据库句柄传递给另外一个进程使用。这主要是由于在好多通用的线程实现（如RedHat9）中的限制引起的（是Bug吗？）。特别的，在有问题的系统上，一个进程创建的 fcntl() 锁无法被其它线程清除或修改。 所以，由于 SQLite 大量使用 fcntl() 锁做并发控制，如果你在不同的线程间移动数据库连接，就可能会出现严重的问题。
在3.3.1版本上，关于在线程间移动数据库连接的限制变得宽松了。 在它及以后的版本中，只要连接没有持有 fcntl() 锁，在线程间移动句柄是安全的。 如果没有未决的事务，并且所有的语句都已执行完毕， 你就可以安全的假定不再持有任何锁。
在UNIX中，在执行 fork() 系统调用时不应携带已打开的数据库进入子进程。 那样做将会有问题。
--------------------------------------------------------------------------------
(7)在SQLite数据库中如何列出所有的表和索引？
如果你运行 sqlite3 命令行来访问你的数据库，可以键入 “.tables”来获得所有表的列表。或者，你可以输入 “.schema” 来看整个数据库模式，包括所有的表的索引。 输入这些命令，后面跟一个LIKE模式匹配可以限制显示的表。
在一个 C/C++ 程序中（或者脚本语言使用 Tcl/Ruby/Perl/Python 等） 你可以在一个特殊的名叫 SQLITE_MASTER 上执行一个SELECT查询以获得所有 表的索引。每一个 SQLite 数据库都有一个叫 SQLITE_MASTER 的表， 它定义数据库的模式。 SQLITE_MASTER 表看起来如下：
CREATE TABLE sqlite_master (
type TEXT,
name TEXT,
tbl_name TEXT,
rootpage INTEGER,
sql TEXT
);
对于表来说，type 字段永远是 'table'，name 字段永远是表的名字。所以，要获得数据库中所有表的列表，使用下列SELECT语句：
SELECT name FROM sqlite_master
WHERE type='table'
ORDER BY name;
对于索引，type 等于 'index', name 则是索引的名字，tbl_name 是该索引所属的表的名字。不管是表还是索引，sql 字段是原先用 CREATE TABLE 或 CREATE INDEX 语句创建它们时的命令文本。对于自动创建的索引（用来实现 PRIMARY KEY 或 UNIQUE 约束），sql字段为NULL。
SQLITE_MASTER 表是只读的。不能对它使用 UPDATE、INSERT 或 DELETE。 它会被 CREATE TABLE、CREATE INDEX、DROP TABLE 和 DROP INDEX 命令自动更新。
临时表不会出现在 SQLITE_MASTER 表中。临时表及其索引和触发器存放在另外一个叫 SQLITE_TEMP_MASTER 的表中。SQLITE_TEMP_MASTER 跟 SQLITE_MASTER 差不多，但它只是对于创建那些临时表的应用可见。如果要获得所有表的列表， 不管是永久的还是临时的，可以使用类似下面的命令：
SELECT name FROM
(SELECT * FROM sqlite_master UNION ALL
SELECT * FROM sqlite_temp_master)
WHERE type='table'
ORDER BY name
--------------------------------------------------------------------------------
(8) SQLite数据库有已知的大小限制吗？
在 Windows 和 Unix 下，版本 2.7.4的 SQLite 可以达到 2的41次方字节 (2T 字节)。老版本的为 2的31 次方字节(2G 字节)。
SQLite 版本 2.8 限制一个记录的容量为 1M。SQLite 版本 3.0 则对单个记录容量没有限制。
表名、索引表名、视图名、触发器名和字段名没有长度限制。但 SQL 函数的名称 (由 sqlite3_create_function() API 函数创建) 不得超过 255 个字符。
对有关SQLite限制的详细讨论，见 limits.html 。
--------------------------------------------------------------------------------
(9) 在SQLite中，VARCHAR字段最长是多少？
SQLite 不强制 VARCHAR 的长度。 你可以在 SQLITE 中声明一个 VARCHAR(10)，SQLite还是可以很高兴地允许你放入500个字符。并且这500个字符是原封不动的，它永远不会被截断。
--------------------------------------------------------------------------------
(10) SQLite支持二进制大对象吗？
SQLite 3.0 及以后版本允许你在任何列中存储 BLOB 数据。 即使该列被声明为其它类型也可以。
--------------------------------------------------------------------------------
(11) 在SQLite中，如何在一个表上添加或删除一列？
SQLite 有有限地 ALTER TABLE 支持。你可以使用它来在表的末尾增加一列，可更改表的名称。如果需要对表结构做更复杂的改变，则必须重新建表。重建时可以先将已存在的数据放到一个临时表中，删除原表，创建新表，然后将数据从临时表中复制回来。
如，假设有一个 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) 我在数据库中删除了很多数据，但数据库文件没有变小，是Bug吗？
不是。当你从SQLite数据库中删除数据时，未用的磁盘空间将会加入一个内部的“自由列表”中。当你下次插入数据时，这部分空间可以重用。磁盘空间不会丢失，但也不会返还给操作系统。
如果删除了大量数据，而又想缩小数据库文件占用的空间，执行 VACUUM 命令。 VACUUM 将会从头重新组织数据库。这将会使用数据库有一个空的“自由链表”， 数据库文件也会最小。但要注意的是，VACUUM 的执行会需要一些时间（在SQLite开发时，在Linux上，大约每M字节需要半秒种），并且，执行过程中需要原数据库文件至多两倍的临时磁盘空间。
对于 SQLite 3.1版本，一个 auto-vacumm 模式可以替代 VACUUM 命令。 可以使用 auto_vacuum pragma 打开。
--------------------------------------------------------------------------------
(13) 我可以在商业产品中使用SQLite而不需支付许可费用吗？
是的。SQLite 在 public domain。 对代码的任何部分没有任何所有权声明。你可以使用它做任何事。
--------------------------------------------------------------------------------
(14) 如何在字符串中使用单引号(')？
SQL 标准规定，在字符串中，单引号需要使用逃逸字符，即在一行中使用两个单引号。在这方面 SQL 用起来类似 Pascal 语言。 SQLite 尊循标准。如：
INSERT INTO xyz VALUES('5 O''clock');
--------------------------------------------------------------------------------
(15) SQLITE_SCHEMA error是什么错误？为什么会出现该错误？
当一个准备好的（prepared）SQL语句不再有效或者无法执行时， 将返回一个 SQLITE_SCHEMA 错误。发生该错误时，SQL语句必须使用 sqlite3_prepare() API来重新编译. 在 SQLite 3 中, 一个 SQLITE_SCHEMA 错误只会发生在用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 执行 SQL 时。而不会发生在使用 sqlite3_exec()时。 在版本2中不是这样。
准备好的语句失效的最通常原因是：在语句准备好后， 数据库的模式又被修改了。另外的原因会发生在：
数据库离线：DETACHed.
数据库被 VACUUMed
一个用户存储过程定义被删除或改变。
一个 collation 序列定义被删除或改变。
认证函数被改变。
在所有情况下，解决方法是重新编译并执行该SQL语句。 因为一个已准备好的语句可以由于其它进程改变数据库模式而失效， 所有使用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 的代码都应准备处理 SQLITE_SCHEMA 错误。下面给出一个例子：
int rc;
sqlite3_stmt *pStmt;
char zSql[] = "SELECT .....";
do {
sqlite3_prepare(pDb, zSql, -1, &pStmt, 0);
while( SQLITE_ROW==sqlite3_step(pStmt) ){
}
rc = sqlite3_finalize(pStmt);
} while( rc==SQLITE_SCHEMA );
--------------------------------------------------------------------------------
(16) 为什么 ROUND(9.95,1) 返回 9.9 而不是 10.0？ 9.95不应该圆整 (四舍五入）吗？
SQLite 使用二进制算术，在二进制中， 无法用有限的二进制位数表示 9.95 。使用 64-bit IEEE 浮点（SQLite就是使用这个）最接近 9.95 的二进制表示是 9.949999999999999289457264
这种问题在使用二进制浮点数的任何时候都会出现。通常的规则是记住很多有限的十进制小数都没有一个对应的二进制表示。所以，它们只能使用最接近的二进制数。它们通常非常接近，但也会有些微小的不同，有些时候也会导致你所期望的不同的结果。
》》》》》》》》》》》》》》
Sqlite中如何返回本地化当前时间？
在做ClinicOS的时候遇到一个问题，在保存病历登记时间时，我使用了 “CURRENT_TIMESTAMP”，但这有个问题，它返回的是UTC Time，这对我们中国人没啥用，一直希望能想办法将它转为localtime。今天刚好有空，所以去查了查Sqlite的Mail List，果然也有人遇到了这个问题，我从一篇名为《translate time comparison statement》（http://www.mail-archive.com/sqlite-users@sqlite.org/msg12350.html）中看到这样的回复：
Mark Wyszomierski wrote:
You may want
WHERE julianday(date('now')) - julianday(date(arrival_date)) > 7
\\\\\\\
Mark,
You should still use the 'localtime' modifier on the 'now' value if your timestamps are local time since 'now' always returns UTC times.
WHERE julianday(date('now', 'localtime')) - julianday(date(arrival_date)) > 7
嘿嘿，看来如果想得到一个符合本机区域设置的当前时间，必须用date函数来转换，
但date只函数只返回当前日期，而我需要的是返回当前日期及时间，所以这里把它换成datetime函数，即：
datetime(CURRENT_TIMESTAMP,'localtime')
以下是sqlite下测试的输出信息：
sqlite> select CURRENT_TIMESTAMP;
2006-06-18 09:23:36
sqlite> select datetime(CURRENT_TIMESTAMP,'localtime');
2006-06-18 17:23:44
sqlite>
SQLITE分页
刚开始的时候没注意语法
后来才发现，原来用SQLite分页是世界上最简单的。
如果我要去11-20的Account表的数据
Select * From Account Limit 9 Offset 10;
以上语句表示从Account表获取数据，跳过10行，取9行
嗯，我觉得这个特性足够让很多的web中型网站使用这个了。
也可以这样写 select * from account limit10,9和上面的的效果一样。
这种写法MySQL也支持。
SQLite适用的范围
SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化:
易于管理
易于使用
易于嵌入其他大型程序
易于维护和配置
许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite力争做到简单化.
简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite省略了一些人们认为比较有用的特性, 例如高并发性、 严格的存取控制、 丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争.
仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候，使用SQLite是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择.
SQLite最佳试用场合
网站
作为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite依然可以正常运行.
嵌入式设备和应用软件
因为SQLite数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序.
应用程序文件格式
SQLite作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数，并且标记一个显式本地事务的起始点（BEGIN TRANSACTION）来保证以独占的方式得到文件的内容. 文件保存将执行一个提交（COMMIT）同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.
数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码.
替代某些特别的文件格式
许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择.
内部的或临时的数据库
对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句.
命令行数据集分析工具
有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV（逗号分隔值文件）文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.
当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事.
在Demo或测试版的时候作为企业级数据库的替代品
如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中，从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证.
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
