32. DROP 与清空表

本节目标：学完本章你能安全删除整张表，并清楚”删除表结构”和”只清空数据保留表结构”是两回事，还会根据场景选择 DELETE 全表还是重建表。

SQLite 是 serverless（无服务进程）/ 零配置 的嵌入式数据库——数据库就是磁盘上的一个单一文件，没有独立的数据库服务在后台运行。正因为如此，“删表”这件在其他数据库里要去服务端执行的操作，在 SQLite 里其实就是在你这个文件里把对应的数据结构抹掉。理解这一点，有助于你建立对 DROP 和清空操作的正确直觉：它们的作用范围只限于当前这个文件，影响的也只是文件里那张表的数据与定义。

一、DROP TABLE：把表连结构带数据一起删掉

当你确定某张表再也不需要了，用 DROP TABLE 一次性把它删除。基本语法如下，方括号里的内容是可选项：

DROP TABLE [IF EXISTS] [schema_name.]table_name;

IF EXISTS 是个很实用的安全开关：如果表存在就删，不存在也不报错；不加它而去删一张不存在的表，SQLite 会直接报错。schema_name. 前缀一般用于附加数据库（用 ATTACH 挂进来的另一个文件），日常单库场景很少用到。

sqlite> DROP TABLE IF EXISTS users;
sqlite> .tables
orders

DROP TABLE 有几个容易被忽略的”连带效果”，务必心里有数：

它会把这张表上依附的对象一并清掉，包括该表的索引（INDEX）和触发器（TRIGGER）。也就是说删表不是只删数据，相关索引、触发器也跟着消失。
DROP TABLE 在删表前其实会先对表做一次”隐式 DELETE”，但由于它先移除了触发器，所以删除触发器不会因此被触发。
它作用于磁盘文件，删了就真没了，没有撤销、没有回收站。这点和误执行 DELETE 还能靠事务回滚不同——DROP 一旦提交，只能靠你之前的备份文件恢复。

Note

重点提示：DROP TABLE 删的是”表定义 + 全部数据 + 依附的索引和触发器”，是不可逆的结构性操作。动手前先确认这张表确实无人再依赖，或者你已经做好了备份（直接复制 .db 文件即可）。

二、清空数据：只删行，保留表结构

很多时候你不想删表，只是想把表里的数据全部清空、保留空表继续用。SQLite 没有 TRUNCATE TABLE 命令（这是 MySQL/PostgreSQL 里的语法，SQLite 不支持），所以清空数据通常有两种做法。

做法 A：用 DELETE 不带 WHERE 删除所有行。

sqlite> DELETE FROM users;
sqlite> SELECT COUNT(*) FROM users;
0

这种方式最简单，语义清晰：把每一行逐个删除，表结构、索引、约束全部原样保留，而且如果你在事务里执行，还可以用 ROLLBACK 反悔。

做法 B：删表再重建（DROP + CREATE TABLE）。

如果表非常大，DELETE 全表会产生大量回滚日志、速度慢；有人会选择先 DROP 再 CREATE。但这种做法会丢失索引、触发器，且不可逆，一般不推荐，除非你明确要重建整个结构。

Tip

实用技巧：日常清空小表，直接用 DELETE FROM 表名; 最省心。只有当你遇到”超大数据表、DELETE 实在太慢且不在乎重建索引”的极端场景，才考虑 DROP 重建，并且记得把索引、触发器一并补建回来。

三、关于”自增归零”的重要纠偏

不少教程会告诉你：清空表后想让自增列从 1 重新开始，要去改系统表 sqlite_sequence。这里必须按官方规范纠偏，否则你会写出错的 SQL：

SQLite 里 sqlite_sequence 这张系统表，只有在你建表时使用了 AUTOINCREMENT 关键字才会存在。如果你用的是推荐的 INTEGER PRIMARY KEY（它已经通过 ROWID 别名实现隐式自增），根本就没有 sqlite_sequence。所以”改 sqlite_sequence 让自增归零”对绝大多数表是不成立的。

-- 推荐写法：隐式自增，没有 sqlite_sequence，不需要也不能去改它
CREATE TABLE users(
  id INTEGER PRIMARY KEY,
  name TEXT,
  age INTEGER,
  email TEXT
);

-- 只有这种写法才产生 sqlite_sequence，且会带来额外开销，一般没必要
CREATE TABLE users(
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT,
  age INTEGER,
  email TEXT
);

即便用了 AUTOINCREMENT，清空数据后新行的 id 也未必从 1 开始，因为 AUTOINCREMENT 的本意恰恰是”永不复用已删除的 ROWID”。所以请记住：清空数据 ≠ 自增归零，这是两个独立的概念。

Warning

常见坑：① SQLite 没有 TRUNCATE，别照搬 MySQL 的 TRUNCATE TABLE。② 外键约束在 SQLite 中默认是关闭的（PRAGMA foreign_keys = OFF）。如果你开启了外键（PRAGMA foreign_keys = ON），DROP 一张被其他表引用的父表可能直接报错；此时需先处理引用关系。每次新连接都要重新 PRAGMA foreign_keys = ON。③ 不要为了”归零自增”去改 sqlite_sequence，普通 INTEGER PRIMARY KEY 表根本没有这张表。

四、什么时候用哪个

要彻底废弃一张表、连同结构一起移除：用 DROP TABLE，记得加 IF EXISTS 防错。
只清空数据、保留空表继续用：用 DELETE FROM 表名;，语义安全且可回滚。
清空后又想从干净状态重新开始：别纠结”自增归零”，重新建库或重新建表往往比折腾序列更干净。

五、两种”清空”的底层差异与误删防护

同样是”数据没了”，DELETE 全表和 DROP 表的底层代价并不一样，理解差异能帮你做对选择：

回滚能力：DELETE 全表如果包在 BEGIN ... ROLLBACK 里，可以一键反悔；DROP 表一旦提交，只能靠备份文件恢复，因为结构本身也被抹掉了。
磁盘与日志：DELETE 逐行删除，会产生与数据量成正比的回滚日志（rollback journal），大表会慢、临时占用也大；DROP 是整体摘除结构，速度快，但不可逆。
索引与触发器：DELETE 保留它们，DROP 会连它们一起删。若误 DROP，补回表时这些附加对象也得手动重建。

因此日常防护很简单：执行 DROP 前，先 SELECT COUNT(*) 确认表还在、数据符合预期；生产环境养成”先复制 .db 文件再操作”的习惯。SQLite 的”数据库即文件”特性在这里反而是优点——备份就是复制一个文件，零成本。

Tip

实用技巧：如果你只是临时想”看一眼空表长什么样”，可以开个事务 BEGIN; DELETE FROM 表名;（查看后）ROLLBACK;，既看到空表效果又不会真删数据。这种”试删即回滚”的小技巧在调试时很省心。

类比小结：DROP TABLE 像是把整本书烧掉（连目录带内容），DELETE 全表像是把书里每一页的内容涂掉但保留这本空书。你要的是哪一种，先想清楚再动手；真要烧书，记得先拍张照（备份）。