【mysql】drop、truncate和delete的区别

说实话，之前我经常混淆这三个命令的使用场景，包括DELETE和TRUNCATE。
我来说说我自己的理解吧。
这可能有点偏离主题，但这绝对是事实。

我第一次使用 DROP 是当我紧急为客户下线测试库时。
当时系统突然崩溃了，数据全乱了，运​​维经理满头大汗。
我上去直接DROP DATABASE mytest1 ;，秒清，空间瞬间释放。
但后来发现有一个旧表没有删除，数据库又炸了。
那一刻我真想给自己一巴掌。
说白了，DROP就是原子删除，不管怎样，一切都会被删除。
有一个小技巧。
使用DROP DATABASE IF EXISTS智能判断不存在则报错。
它非常人性化。

TRUNCATE 给我印象最深的是日志表的处理。
这种巨大的表每天包含数百万条数据。
如果用DELETE一一删除的话，在死之前是无法全部删除的。
换成TRUNCATE，TRUNCATE TABLE log_table;，一键清空一切，连索引都保留下来，程序第二天还能运行。
释放空间也比DELETE更快，因为MySQL直接截断表文件并重置数据文件。
但有一个问题。
上次使用TRUNCATE清表后，忘记同步保存数据了。
结果DBA找我谈话，告诉我数据无法恢复。
我自己没有执行过，但我的预感是这是一个 DDL 操作，恢复基本上是一个梦想。

DELETE 是我最常用的命令，尤其是带有 WHERE 条件时。
例如清除某个用户的订单，DELETE FROM Orders WHERE user_id = 1 00;，只删除特定数据。
有一个非常重要的细节，DELETE就是DML并且可以撤消。
上次SQL写错了，不小心把条件写反了。
幸运的是，自动提交被禁用。
赶紧ROLLBACK，不然损失惨重。
但一位朋友告诉我，大量使用 DELETE 会锁定表。
他表示，他删除了数十万条数据，公司系统长时间卡住。
释放空间是延迟加载，您应该使用 OPTIMIZE TABLE 对碎片数据进行排序。

相比之下，DROP是核武器，TRUNCATE是清道夫，DELETE是手术刀。
选择取决于场景：如果要完整数据库，则使用DROP，如果要快速清表，则使用TRUNCATE，如果要精确删除数据，则需要DELETE。
从性能上来说，TRUNCATE确实更快。
我有一个2 00G的表。
DELETE 将花费很长时间，但 TRUNCATE 可以在几分钟内完成。

顺便说一句，我理解你提到的示例图像，对吗？ DELETE可以撤消，因为它保存日志，TRUNCATE不能撤消，因为它直接破坏表结构，而MySQL懒得保存。
之前跟DBA确认过这一点，他说就是这个原理。

MySQL DELETE语句和TRUNCATE TABLE语句的区别

嘿，朋友们，说实话，我在数据库工作了这么多年。
DELETE 和 TRUNCATETABLE 这两个东西实际上就像两种不同的健身方法，每种方法都有自己的方法。

有一次，我记得是2 01 6 年，当时我在一家小公司做数据库，公司领导说一个表数据太多了，需要清理一下。
我开始用DELETE来一一删除。
那时，表中可能有数百万条记录。
结果我就等啊等啊。
删除速度慢如蜗牛。
这非常令人沮丧。

然后稍微懂点的同事小王向我推荐了TRUNCATETABLE，于是我就尝试了一下，发现速度奇快，但是和DELETE相比，根本不算什么。
当时我就觉得这个TRUNCATABLE就像是一口气把健身房里的设备都清空了一样。
真是太清爽了！
但是，两者之间还是有区别的。
比如DELETE可以回滚，出错了还可以恢复。
TRUNCATETABLE 很麻烦。
回滚功能有时不可靠。
就像健身时如果动作做错了，可能就很难恢复了。

还有，我在项目中使用了TRUNCATETABLE，发现AUTO_INCRMENT计数器被重置，又从0开始计数，这让我很不高兴。
后来我改用DELETE，至少AUTO_INCRMENT可以继续。

总的来说，DELETE就像一条长长的水流，适合日常的小规模操作，而TRUNCATETABLE相当于一次一般性的清理，适合大规模的数据清理。
不过，对于非专业人士来说，确实不建议乱用TRUNCATETABLE。
如果数据不小心丢失了，你向谁哭呢？