SQLite 命令速查
元命令 / DDL / DML / FTS · 点击复制
第一节
关于本工具
About敲 .schema 看表结构，结果表名多了个 s，又敲一遍。.import 想把 CSV 塞进去，分隔符没对上，数据全挤进一个字段。这些元命令的拼写、参数顺序、输出格式，每次用都得翻文档或靠肌肉记忆赌一把。这个速查表把 .tables、.schema、.import、.output 等常用元命令的精确语法和典型输出样例列在一起，不用离开键盘就能确认。所有内容静态渲染，不联网，不记操作。
使用场景
数据库表结构遗忘
接手一个三年前的订单管理系统，表名只记得大概叫 'orders' 或 'order_info'。直接 .tables 列出所有表，再用 .schema orders 一秒看到建表语句：字段名、类型、主键、外键约束全出来。不用打开几百行的 SQL 建表脚本文件，也不用翻找陈旧的数据库设计文档。
CSV 数据灌入 SQLite
市场部发来一份 2 万行客户数据的 CSV 文件，要求导入测试库做关联查询。打开 SQLite 后，先 .import --csv customers.csv customers 直接创建表并导入数据。再用 .schema customers 确认字段类型是否正确（比如手机号是否被当成 INTEGER 截断）。整个过程不写一行 INSERT 语句。
排查索引是否生效
一个报表查询从 0.3 秒突然变成 8 秒，怀疑是索引失效或没建。用 .indices orders 查看订单表上所有索引名称，再用 .schema idx_order_date 看索引定义（包含哪些列、是否唯一）。对比查询的 WHERE 条件，发现日期索引建在了 id 列上，当场纠正。
迁移数据库前摸底
要把一个 200MB 的 SQLite 文件迁移到 PostgreSQL，需要先知道里面到底有多少张表、每张表的字段和约束。用 .tables 列出全部 37 张表，再用 .schema 逐一导出建表语句。发现一张 'logs' 表有 23 个字段和 5 个索引，提前准备迁移脚本的映射关系，避免上线后字段对不上报错。
调试触发器逻辑
用户反馈删除订单后，库存数量没有自动回滚。用 .schema 查看订单表和库存表上的触发器定义，发现触发器 AFTER DELETE 里写错了库存表的更新条件（把 'product_id' 写成了 'order_id'）。修改后再次 .schema 确认语法正确，不用反复执行 SELECT 去猜触发器干了什么。
查看数据库版本兼容性
从客户服务器拿回一个 SQLite 数据库文件，本地打不开。用 .version 查看本地 SQLite 版本是 3.31.0，客户的是 3.8.0。再用 .schema 检查表里是否用了窗口函数（如 ROW_NUMBER），确认该特性在 3.25.0 之后才支持，决定升级本地环境而非修改数据库结构。
第二节
使用指南
Getting Started使用步骤
- 1在输入框键入一条 SQLite 元命令（如 `.tables`），按回车立即在下方输出区显示执行结果
- 2输入 `.schema 表名` 可查看指定表的建表语句，输出区直接显示 CREATE TABLE 全文
- 3输入 `.import 文件路径 表名` 可导入 CSV 文件，输出区会提示导入的行数或错误信息
- 4输入 `.help` 列出所有可用元命令及其说明，输出区按字母顺序展示完整列表
- 5输入 `.quit` 退出当前会话，输出区清空并返回初始状态
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| .schema | CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT); CREATE INDEX idx_name ON users(name); | 常规：无参数时输出所有表及索引的建表语句，验证速查表对基础元命令的覆盖 |
| .schema users | CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT); | 常规：带表名参数，只输出指定表的结构，验证速查表对参数用法的说明 |
| .import /data/input.csv mytable | 导入成功：从 /data/input.csv 读取 100 行数据写入 mytable 表。 | 边界：CSV 文件路径含空格时需加引号，速查表应提示路径转义规则 |
| .import data.csv nonexistent | 错误：表 'nonexistent' 不存在。请先用 CREATE TABLE 创建目标表。 | 边界：导入到不存在的表时 SQLite 默认报错，速查表需说明必须先建表 |
| .schema "table with spaces" | CREATE TABLE "table with spaces" (id INTEGER); | 易错：表名含空格或特殊字符时必须用双引号包裹，速查表应强调引号用法 |
| .import data.tsv mytable --csv | 错误：选项 --csv 与文件扩展名 .tsv 冲突。请使用 .separator 先设置分隔符。 | 易错：.import 的 --csv 选项与文件扩展名不匹配时易混淆，速查表应列出分隔符设置方法 |
| .schema users | 错误：表 'users' 不存在。 | 边界：查询不存在的表名时返回错误，速查表可提示先用 .tables 确认表名 |
常见错误对照
1.导入 CSV 时未指定分隔符，导致字段错位
✗ 错误
.import data.csv my_table✓ 修复
.import --csv data.csv my_table默认 .import 按 ASCII 空格和制表符分割，CSV 文件用逗号分隔，不指定 --csv 会将整行当一列，字段全部错位。
2.查看表结构时漏掉点号，执行了 SQL 语句
✗ 错误
schema users✓ 修复
.schema users点号是 SQLite 元命令前缀，漏掉点号后 SQLite 会当作普通 SQL 执行，报错 'no such table: schema'。
3.导出时用 .mode list 导致空字段丢失
✗ 错误
.mode list
.output data.txt
SELECT * FROM t;✓ 修复
.mode csv
.output data.csv
SELECT * FROM t;.mode list 用分隔符（默认 |）连接字段，NULL 输出为空字符串，无法区分空字段和 NULL，且字段内若有分隔符会破坏结构。
4..import 时目标表不存在，自动建表类型全为 TEXT
✗ 错误
.import data.csv new_table✓ 修复
CREATE TABLE new_table (id INT, name TEXT);
.import data.csv new_tableSQLite 在目标表不存在时会自动建表，但所有列类型强制为 TEXT，丢失 INT/REAL 等数值类型，后续查询排序会出错。
5.使用 .dump 后误以为包含索引和触发器
✗ 错误
.dump my_table✓ 修复
.dump my_table # 实际包含索引和触发器.dump 默认输出表结构、数据、索引和触发器，但很多用户以为只输出数据，用 .dump 恢复时发现已有索引冲突。
6.在 .import 前忘记设置 .mode，导致空行被跳过
✗ 错误
.import data.csv t✓ 修复
.mode csv
.import data.csv t未设 .mode csv 时，.import 按行读取，空行会被当作结束标记而跳过，导致后续数据全部丢失。
7.用 .headers on 后输出仍无列名，误以为设置无效
✗ 错误
SELECT 1 AS a;✓ 修复
.headers on
SELECT 1 AS a;.headers on 只影响后续 SELECT 的输出，不影响已执行的查询。需在查询前设置。
8.在 .separator 后误用空格，导致分隔符失效
✗ 错误
.separator ,✓ 修复
.separator ,.separator 参数之间不能有空格，否则 SQLite 会将空格也视为分隔符一部分。正确写法是 .separator ,（无空格）。
第三节
工作原理
How It Works核心公式
.schema 表名 → 返回该表的 CREATE TABLE 语句
变量说明
表名数据库中的表名称，如 users
示例
数据库中有表 users，执行 .schema users 返回：CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER); 该命令直接输出建表 DDL，无计算过程。
用户输入
本地处理
输出结果
第五节
常见问题
Q & A问我输入 .schema 没反应，是不是工具坏了？＋
答
不是工具问题。.schema 是 SQLite 命令行工具的元命令，不是标准 SQL 语句。本页面为纯前端实现，模拟了部分常用元命令的解析，但 .schema 依赖当前连接的数据库文件结构信息。如果你没有先通过本工具“打开/上传一个 .db 文件”或“粘贴建表语句”，.schema 没有数据可返回。正确流程：先在输入区上传或粘贴一个完整的 SQLite 数据库内容，再执行 .schema。
问.import 命令怎么用，我直接写 .import a.csv mytable 不行？＋
答
本工具 .import 的语法与 SQLite 官方 CLI 略有不同，因为纯前端无法直接读取你本地文件路径。正确用法：先点击“上传 CSV 文件”按钮选择文件，工具会自动读取内容并填入一个临时表；然后执行 .import 时只需要指定目标表名（如 .import mytable），不需要文件路径。如果目标表不存在，工具会按 CSV 首行字段名自动建表。
问为什么我执行 .tables 只显示一条记录，但我数据库明明有十几个表？＋
答
检查你是否只上传了部分数据。本工具支持两种方式加载数据库：1) 上传完整 .db 文件（推荐）；2) 粘贴 SQL 建表语句。如果只粘贴了一条 CREATE TABLE 语句，.tables 自然只返回那一张表。另外，如果你上传的是 .db 文件但文件损坏或加密（如 SQLCipher），工具也无法读取全部表结构。建议先确认文件完整性，用 SQLite 官方工具打开验证。
问.dump 导出来的 SQL 能直接拿去重建数据库吗？＋
答
可以，但需要注意两个点。第一，.dump 输出的是纯 SQL 语句集合，包含 CREATE TABLE 和 INSERT INTO，直接复制到 SQLite 命令行或本工具的 SQL 执行区运行就能重建。第二，本工具 .dump 不会导出索引、触发器或视图的定义（受限于纯前端解析能力），如果你的数据库依赖这些对象，建议改用 SQLite 官方命令行工具执行 .dump。
问我粘贴了一个 10MB 的 SQL 文件进去，页面卡死了怎么办？＋
答
本工具运行在浏览器中，所有数据处理都在本地完成，不经过服务器。10MB 的纯文本对浏览器来说确实有压力，尤其是进行语法解析时。建议：1) 拆分成多个小文件分批处理；2) 使用桌面版 SQLite 工具处理大文件；3) 如果只是查结构，只上传 .db 文件而不粘贴全部 SQL。本工具更适合 2MB 以下的 SQL 脚本或小型 .db 文件。
问.mode 命令有什么用，我不用会怎样？＋
答
.mode 控制查询结果的显示格式。默认是 list 模式（每列用竖线分隔），如果你执行 SELECT * FROM users，结果会像 1|张三|28。如果改成 .mode column，结果会按列对齐，表头也显示出来，更易读。本工具默认使用 column 模式，但如果你需要将结果复制到 Excel 或 CSV，可切换为 .mode csv 或 .mode tabs。不设 .mode 也不影响查询执行，只影响展示样式。
问这个工具和 SQLite 官方命令行工具有什么区别？＋
答
核心区别：本工具是纯前端网页，无需安装，打开浏览器就能用；官方 CLI 需要下载安装 SQLite 可执行文件。功能上，官方 CLI 支持全部元命令和高级功能（如 .backup、.clone、.selftest），本工具只覆盖最常用的 10 多个元命令（.schema、.tables、.import、.dump、.mode 等）。如果你只需要快速查看数据库结构或做简单导入导出，本工具更方便；如果需要完整数据库管理，建议用官方 CLI 或 DB Browser for SQLite。
问我上传的 .db 文件会不会被传到服务器？我担心数据泄露。＋
答
不会。本工具为纯前端实现（FE），所有文件读取、解析、执行都在你的浏览器本地完成，没有任何数据上传到任何服务器。你可以断网测试：先打开页面，再断开 Wi-Fi，上传 .db 文件后执行 .schema 和 .tables 依然正常工作。这也是本工具设计为纯前端的原因——用户处理敏感数据库时无需担心数据外泄。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。