06. 创建第一个数据库与数据表

本节目标：学完本章你能用 sqlite3 命令行创建一个 SQLite 数据库文件、建立 users 表、插入并查询第一条数据，跑通最小读写闭环。

在 MySQL、PostgreSQL 这类传统数据库里，你得先启动一个独立的”服务进程”（server），客户端再连上去干活。SQLite 完全不是这样。它最大的特征就是 serverless（无独立服务进程）、零配置（zero-configuration）：整个数据库其实就是硬盘上的一个普通文件，比如 mydb.db。你想用的时候，程序直接打开这个文件读写就行，不需要安装、启动、配置任何后台服务，也不需要一个”数据库管理员”在旁边守着。

把 MySQL 比作一家需要专人照看的后厨——开店前得先雇厨师（起服务）、租店面（配服务器）、排班（做权限），而 SQLite 更像一个你随手拎着的饭盒：饿了（要读写数据）打开盖子就能吃，吃完合上就行，数据库就是那个饭盒文件。理解了这一点，后面所有操作都会变得特别简单。

为什么这种”数据库即单个文件”的模型值得你记住？因为它带来几个非常实在的好处。第一，部署极简：你要把数据库从一台机器搬到另一台，复制那个 .db 文件就完事了，没有”导出再导入”的繁琐流程。第二，备份就是复制文件，甚至可以在程序关闭时直接打包，灾难恢复成本极低。第三，嵌入式设备、手机 App、桌面软件、浏览器、爬虫脚本都能直接内置 SQLite，不需要联网到远程服务器，单机就能跑得稳稳的。

现在我们动手，用上一章装好的 sqlite3 命令行工具来建第一个库。打开你的终端（命令行窗口），进入一个你想放数据库文件的目录，然后执行下面这行：

sqlite3 mydb.db

执行之后，如果看到类似 SQLite version 3.53.4 ... 的欢迎信息和 sqlite> 提示符，说明成功了。请注意一个关键点：这一步其实已经把数据库文件创建出来了——即使你还没建任何表、没写一行数据，mydb.db 这个文件此刻已经安静地躺在当前目录里了。换句话说，“建库”在 SQLite 里几乎是零成本的，没有专门的 CREATE DATABASE 语句，打开文件即建库。

实用技巧

如果你已经处在 sqlite> 提示符里（比如刚打开 sqlite3 没带文件名），可以用 .open mydb.db 来创建或打开数据库。文件不存在就新建，存在就直接打开，比退出重进方便得多。

数据库文件有了，但里面还是空的。接下来我们建第一张表 users。还记得本教程全程统一使用的示例表吗：

users(id INTEGER PRIMARY KEY, name TEXT, age INTEGER, email TEXT)

把它真正建出来的语句是：

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT,
  age INTEGER,
  email TEXT
);

注意结尾的分号 ;，在 sqlite> 提示符里每条 SQL 语句都要以分号结束。建完之后，用点命令看看表是否真的存在：

sqlite> .tables
users
sqlite> .schema users
CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT,
  age INTEGER,
  email TEXT
);

.tables 列出当前库里所有表，.schema 表名 显示建表语句。这两个点命令（以英文点开头）是 sqlite3 自带的”元命令”，不是 SQL，不用加分号。

表建好了，现在插入第一条数据：

INSERT INTO users (name, age, email) VALUES ('张三', 28, 'zhangsan@example.com');

留意我们没有给 id 赋值。这正是 SQLite 一个很贴心、却也最容易被误解的设计，必须重点说清楚。

常见坑

很多人从别的数据库过来，以为”自增主键”必须写 AUTOINCREMENT 关键字。在 SQLite 里这是错的，而且是个常见坑。INTEGER PRIMARY KEY 已经会隐式自增：它本质上是表内部 rowid 的别名，当你插入一行却不指定 id 时，SQLite 会自动分配一个比当前最大值更大的整数。只有当你处于”坚决不允许复用被删除过的 id”这种极少见的场景，才需要额外加 AUTOINCREMENT 关键字——而它会引入 sqlite_sequence 系统表并带来一点点性能和空间开销。入门阶段、以及绝大多数日常项目，直接用 INTEGER PRIMARY KEY 就够了，千万别画蛇添足。

既然插入了，马上把数据查出来验证一下：

sqlite> SELECT * FROM users;
1|张三|28|zhangsan@example.com

SELECT * FROM users; 表示”从 users 表里查所有列的所有行”。默认输出用竖线 | 分隔各列，这是 sqlite3 的清单模式。你可以用 .mode column 和 .headers on 让显示更好看（这两个点命令在 CLI 入门章讲过）。到这里，建库 → 建表 → 插入 → 查询的最小闭环就完整跑通了。

作为对照，我们再用同样的方式建第二张示例表 orders：

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER,
  amount REAL,
  created_at TEXT
);

这里要特别提醒 created_at 这一列：我们把它声明成了 TEXT，而不是什么 DATE 或 DATETIME 类型。这不是随意的，而是 SQLite 的正确做法——

常见坑

SQLite 没有 DATE、TIME、DATETIME、TIMESTAMP 这几种”日期类型”。它只有 5 种存储类（NULL / INTEGER / REAL / TEXT / BLOB），日期时间应当存成 TEXT（推荐 ISO8601 文本，如 '2026-07-31 10:00:00'）、或 REAL（儒略日数）、或 INTEGER（Unix 时间戳秒数），再由内置的日期函数去解析和运算。把 created_at 写成 TEXT 是标准做法。关于”为什么 SQLite 没有日期类型”，第 08 章会用一整章彻底讲透，这里先记住结论即可。

那么，什么时候该用这种”建库就是建文件”的方式？几乎所有单机、嵌入式、本地工具类程序都适合：手机里的通讯录、桌面笔记软件、聊天记录、爬虫抓下来的临时结果仓库、单元测试时临时建的库、甚至网页浏览器里存的 cookie 和缓存。反过来，如果你需要几百个客户端同时高频写入同一份数据、或者数据量要上 TB，那才该考虑 MySQL/PostgreSQL 这类”后厨型”数据库。选哪种，看场景，别盲目。

重点提示

本章请务必记住三件事：① 数据库就是 mydb.db 这么一个普通文件，没有服务进程、零配置；② 建表用 CREATE TABLE，列上写的类型只是”亲和性建议”（这点第 08 章细讲），当前先照着统一示例表写；③ 主键用 INTEGER PRIMARY KEY 就能隐式自增，别急着上 AUTOINCREMENT。

最后用一个类比把本章串起来：建库，就像新建一个 Excel 文件；建表，就像在这个文件里新建一个工作表并定好表头；插入数据，就像往表格里填一行；查询，就像用筛选功能把某些行显示出来。Excel 文件在哪，数据库就在哪；你不需要为用 Excel 专门起一个”Excel 服务”。下一章我们退一步，从整体看看 SQL 这门语言到底由哪些部分组成，帮你把已经会的点滴操作归到正确的分类里。