果不其然，SQLite的研究引来一堆人的关注，上一篇爆了

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

上一篇不知道是怎么了，一堆加群的人，看来SQLite 的确是数据库流量密码，留言板也人数超多，世界装机量最大的数据库，这是有道理的。

本来今天是一期为什么SQLite3是装机最多的数据库，且打败了PostgreSQL的分析，但留言板里面很多希望一期学习的人，那么这期咱们就继续学习SQLite。

这里我总结几个部分后续要进行学习和分享

1 Sqlite的数据库体系结构上是什么，表怎么建立，建立表的方式和别的数据库有什么不同。

2 Sqlite的数据库特点是什么，使用中的需要注意的部分，比如他是一个读并发，写单线程的，带有库锁的数据库

3 Sqlite 数据库，配置，运维，以及运维

4  如何设计一个应用程序在Sqltie 中

以上四个问题是我们后续要进行的，并和大家分享的、

---

今天我们现开始学习，sqlite的常用的知识，以及一些操作命令然后我们在对一些简单的SQLite的命令进行简单的学习，本篇是开始学习SQLite的第三天。

SQLite 作为轻量级的数据库，其数据库类型体系与传统的数据类型差异是很签注的额，从数据库类型上看，他的主要核心是围绕动态类型，和兼容类型他的数据类型并不精准，而是围绕灵活性而来。

SQLite的第一个区别就是动态类型，比如我们PostgreSQL中INT，我们只能存储数据类型，而SQLite不是的，即使你声明的表类型是INT，他也可以存储字符串类型，浮点等，列定义仅仅作为参考，不做强制。

后面在SQLite中又有strict表，这类表才是严格和传统数据库类型强制一致的表，如果有此类需求需要建表的时候建立strict表。

SQlite的数据类型主要有五种，NULL, INTEGER ,REAL, TEXT, BLOB 等，这里SQLite里面是没有时间类型的，时间类型需要转化，通过date, strftime函数来进行。

日期时间类型：无独立存储类，需通过以下 3 种格式存储，再用内置日期函数（如 date()、strftime()）转换：

TEXT：ISO8601 格式（如 2024-11-14 12:00:00）； REAL：儒略日（自公元前 4714 年 11 月 24 日格林威治正午起的天数）； INTEGER：Unix 时间戳（自 1970-01-01 00:00:00 UTC 起的秒数）

这里需要注意如果建立不同表，那么你输入的类型如果是5.0 会自动转化为 5整型，而不是浮点类型 real。

可能是随着SQLite使用的越来越多，作为移动端的数据越来越重要，那种数据库把你的数据类型转错的情况就发生了，所以后续的SQLite有新的一个表类型strict，建立表需要建表的末尾添加strict 也就是严格模式。

列类型强制要求

所有列必须显式指定类型，不能省略； 仅允许 6 种类型：INT、INTEGER、REAL（浮点）、TEXT（字符串）、BLOB（二进制）、ANY（任意类型），无其他可选类型（未来可能新增）。

（2）数据插入规则

非ANY类型列：插入数据需是NULL（无NOT NULL约束时）或匹配列类型；SQLite 会按 “类型亲和性规则” 尝试转换（与其他数据库一致），无法无损转换则抛出SQLITE_CONSTRAINT_DATATYPE错误（例：INTEGER列插入'xyz'会报错）。 ANY类型列：可接受任意类型数据（NOT NULL约束时拒绝NULL），不做任何类型转换，完全保留原始数据类型与值。

（3）主键与完整性检查

主键列隐式包含NOT NULL约束；但INTEGER PRIMARY KEY列插入NULL时，会自动转为唯一整数（与非严格表规则一致）。 PRAGMA integrity_check/quick_check命令会检查 STRICT 表的列类型，异常时提示错误。

（4）与非严格表的共性 除上述差异外，STRICT 表的其他特性与普通表完全一致，包括：CHECK/NOT NULL/FOREIGN KEY/UNIQUE约束、DEFAULT/COLLATE子句、生成列、ON CONFLICT处理、索引、AUTOINCREMENT、INTEGER PRIMARY KEY作为rowid别名、磁盘存储格式等。

1. ANY 数据类型：特殊规则 设计目的：在严格模式下，仍支持 “单列存储任意类型数据” 的灵活能力（SQLite 独有特性）。

STRICT 表 vs 非严格表的差异： STRICT 表的ANY列：完全保留原始数据（例：插入'000123'，存储为text类型的'000123'）； 非严格表的ANY列：会尝试将 “类数字字符串” 转为数值（例：插入'000123'，存储为integer类型的123）。

1. 向后兼容性

（1）版本限制 仅 SQLite 3.37.0 及以上版本能识别STRICT关键字；低版本打开含STRICT表的数据库时，默认报错（除特殊情况外）。 不含STRICT表的数据库，3.37.0 及以上版本创建后，仍可被低至 3.0.0（2004 年）的版本读写。

（2）低版本访问 STRICT 表的特殊方式 低版本可通过打开数据库后立即执行PRAGMA writable_schema=ON（关闭 schema 解析错误），忽略STRICT关键字并读写表，但不会触发严格类型检查（可能导致数据类型错误，需用高版本PRAGMA quick_check检测）。 SQLite CLI 的.dump命令默认启用writable_schema=ON，低版本用.dump可读写 STRICT 表，但同样存在数据损坏风险。

1. 其他表选项 CREATE TABLE语句末尾（闭合括号后）可接逗号分隔的表选项，目前仅支持 2 种： STRICT（严格类型）、WITHOUT ROWID（无rowid表）； 选项顺序不限，当前版本允许重复选项（未来可能取消，不建议依赖）。

所以针对业务，希望开发人员在3.37版本后的SQLite应该这对业务中的一些精确的数字，或者数字就是文字的部分应该严格，建表就要建立一个严格的表。

CREATE TABLE orders (order_id  INTEGER PRIMARY KEY,order_no TEXT NOT NULL UNIQUE,customer_id  INTEGER NOT NULL,amount REAL NOT NULL,pay_type  TEXT CHECK(pay_type IN ('CARD','CASH','WALLET')),created_at TEXT NOT NULL,raw_payload  ANY,note TEXT,FOREIGN KEY (customer_id) REFERENCES customers(id)) STRICT;

SQLite 并不需要启动，你可以认为他是一个程序，通过SQLite 数据库文件名，就可以进入到数据库进行操作。

查看系统的版本 sqlite> .version SQLite 3.47.1 2024-11-25 12:07:48 b95d11e958643b969c47a8e5857f3793b9e69700b8f1469371386369a26e577e zlib version 1.2.11 gcc-8.5.0 20210514 (Red Hat 8.5.0-28) (64-bit) sqlite>

对Sqlite的日常命令不熟悉，可以通过.help进行更详细的命令的问询

对sqlite中的有多少表进行询问

查看有多少表使用 .table .schema 表名 查看表结构

sqlite> 
sqlite> .tables
id         test_data
sqlite> .schema test_data
CREATE TABLE test_data (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 name TEXT,
 value INTEGER,
 created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
sqlite> 

这里sqlite有自己的系统表结构，可以通过来进行查看

sqlite> select * from sqlite_master;
table|id|id|2|CREATE TABLE id (id int)
table|sqlite_sequence|sqlite_sequence|4|CREATE TABLE sqlite_sequence(name,seq)
table|test_data|test_data|3|CREATE TABLE test_data (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT,
  value INTEGER,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)
Run Time: real 0.000 user 0.000020 sys 0.000039

具体我们查看表名前缀为test的表

这里遇到一个问题，在对表进行删除的过程中，发现报错

遇到此问题，目前最快速的方案是，退出SQLite然后在进入进行命令的操作。

总结: SQLite在我使用中，经常有database lock的错误产生，（因为我还是用传统数据库思维去操作的问题），解决也很简单，查杀链接，或把.quit数据库即可，解决库锁的问题。在操作中命令不支持上下箭头来进行历史命令的查找，建表要注意宽松模式和严苛模式，其实我逐步对SQLite的深入，我其实对他有很多的问题。

1 SQLLite数据支持数据压缩吗，因为我现在一个表，几百万的数据就270MB的文件大小了，说明这个数据库本身数据的文件的控制有问题，应该有可以进行碎片整理的命令，这个我看到了，但我还没有深入。

2 在研发中，使用SQLite3 如何进行开发和库表的使用，用传统数据库使用思路是一定不行的，还需要打破原有的设计思路来避免库锁的问题。

3 因为我曾经有一次服务器重启，然后进入SQLite特别慢的经历，说明断电对第一次SQLite启动是有阻碍的，应该是wal模式下数据在重做导致的，但是一个关键的问题，SQLite 没有日志，没有错误的报告等等，这些还需要研究。

MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项

MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"

MongoDB “升级项目”  大型连续剧(1)-- 可“生”可不升

MongoDB  大俗大雅，上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通

MongoDB 年底活动，免费考试名额 7个公众号获得

MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模