6.3 DROP 删除数据库与表

6.3 DROP 删除数据库与表

本节摘要：DROP 删除数据库对象——表、库、视图等。本节讲 DROP 语法、和 DELETE/TRUNCATE 的区别，以及它不可恢复的高风险。

本节目标

阅读完本节，你应当能够：

1. 用 DROP 删表删库
2. 区分 DROP/DELETE/TRUNCATE
3. 理解 DROP 的不可恢复性
4. 养成删结构对象的安全习惯

概念脉络

一、DROP 语法

DROP TABLE Products;        -- 删表（含所有数据和结构）
DROP DATABASE Shop;          -- 删库（含所有表和数据）
DROP VIEW view_name;         -- 删视图
​

DROP 删的是"结构对象本身"——表删了，表结构、数据、索引、约束全没了，不像 DELETE 只删数据保留结构。

二、DROP vs DELETE vs TRUNCATE

三者都能"清掉数据"，但层次不同：

DELETE FROM Products WHERE id = 1;   -- 删一行，表还在
TRUNCATE TABLE Products;              -- 清空表数据，表结构在
DROP TABLE Products;                  -- 表彻底没了
​

三、不可恢复的高风险

DROP 删掉的是结构对象本身，删完表/库就没了，数据也跟着没了。除非有备份，否则不可恢复。这是 SQL 里最危险的操作之一。

图 6-3 三种删除的层次

四、安全删除

DROP 不可恢复，安全做法：

1. 确认对象名：再三核对要删的表名/库名，避免误删。
2. 用 IF EXISTS：DROP TABLE IF EXISTS Products，对象不存在也不报错。
3. 先备份：删前备份，留恢复余地。
4. 先重命名确认：生产删表前先 RENAME TABLE Products TO Products_to_delete，观察一段时间无引用再真删。
5. 权限管控：DROP 权限严格限制，普通账号不给。

-- 安全删表：先改名观察
RENAME TABLE Products TO Products_to_delete;
-- 观察一段时间无报错后
DROP TABLE Products_to_delete;
​

五、级联删除

删表时如果有视图、外键依赖，可能报错或需要级联处理。部分 DBMS 支持 DROP TABLE ... CASCADE 级联删依赖对象，但慎用——会连带删一堆。

⚠️ 常见坑：DROP 误删生产表/库，且不可恢复。删前务必核对对象名、备份、先重命名观察。DROP 权限严格管控，普通账号不给。

💡 关键直觉：DELETE 删行、TRUNCATE 清表、DROP 删表本身——层次递增，危险递增。DROP 不可恢复，是 SQL 最危险操作，删前备份、改名观察、权限管控三件套。

温故知新

• DROP：删表/库/视图等结构对象，结构和数据全没。
• vs DELETE/TRUNCATE：DELETE 删行保留表、TRUNCATE 清空保留表、DROP 删表本身。
• 不可恢复：删完回不来（除非备份），是 SQL 最危险操作。
• 安全：核对对象名、用 IF EXISTS、先备份、先重命名观察、权限管控。
• 级联：有依赖可能报错，CASCADE 级联删慎用。

第 6 章结束。建表、改表、删表三件套掌握。最后一章看进阶概念——视图、索引、事务、权限。

常见疑问

Q1：DROP、TRUNCATE、DELETE 到底差在哪？

DELETE 删数据（可带 WHERE、事务内可回滚、触发触发器）；TRUNCATE 清空数据（保留表、一般不可回滚、不触发触发器）；DROP 连根拔起（表和结构都没了、不可恢复、不触发触发器）。一句话：DELETE 删数据，TRUNCATE 清空数据，DROP 连根拔起。

Q2：DROP 前要做什么准备？

1. 确认对象名没拼错（删错表是最高频事故）；2) 备份（导出表结构+数据）；3) 确认没有其他对象依赖（视图、外键、存储过程）；4) 有条件先 RENAME 改名观察，确认无误再 DROP。

Q3：DROP TABLE IF EXISTS 是什么？

不存在时也不报错，适合脚本幂等执行：DROP TABLE IF EXISTS tmp_xxx。脚本重跑不中断。但对生产表别滥用 IF EXISTS 掩盖"表竟然不存在"的异常。

Q4：为什么生产环境不建议随便给 DROP 权限？

权限最小化原则：普通开发账号不需要 DROP（表结构变更应走审批流程）。DBA 或变更工具才持有 DROP 权限。这样即使误操作或注入，破坏面也有限。

Q5：删了表还能恢复吗？

看备份策略：有定期备份+binlog 可以恢复（需要 DBA 操作）；没有备份就只能认栽。这也是为什么 DROP 是"最后手段"。养成"删前备份、软删除优先"的习惯。

动手做一做

删除结构的危险程度最高，但正因为如此，才值得在测试库里完整演练一遍。

准备一张练习表，插入若干行数据。

第一步，分别执行删除单行、清空表、删除整表三种操作，逐层观察它们的区别：一个只删行还留表，一个清空数据还留结构，一个连结构一起消失。

第二步，在删除整表之前，先给表改名，模拟生产环境"改名观察"的做法，体会这个保险动作的思路。

第三步，尝试删除一个被其他表引用的父表，观察报错信息，理解依赖关系会阻止删除。

第四步，把删除整表的语句放进事务里执行，看能否回滚，理解不同数据库对结构操作回滚的支持差异。

第五步，用带条件判断的删除写法，让脚本在表不存在时不报错，体会它在自动化脚本中的价值。

这五步做完，删除数据、清空表、删除表三者的界限，依赖关系对删除的约束，以及安全删除的套路，就都清楚了。删除是数据库里最该敬畏的操作，现在多演练，将来少出事。

一句话记忆

删除由轻到重分为删行、清空、删表三层。删行留结构可回滚，清空留结构不可回滚，删表连结构一起消失。删前备份、改名观察、管控权限，是使用删除的三条铁律。