DELETE用于条件删除或需事务回滚的场景，逐行操作、保留自增ID、触发触发器；TRUNCATE快速清空整表、重置自增ID、不可回滚；DROP彻底删除表结构及所有相关对象。
DELETE 用在需要条件过滤或事务控制的场景
当你只删部分行、要保留自增ID连续性、或者操作必须能回滚时，DELETE 是唯一选择。它本质是逐行DML操作，会写undo log和redo log，触发器也会执行。
常见错误现象：漏写 WHERE 子句，导致全表误删；在大表上无限制地执行 DELETE FROM table_name，引发长时间锁表、undo日志暴涨、主从延迟飙升。
- 必须显式加
WHERE条件，且条件字段最好有索引，避免全表扫描 - 删除超10万行时，建议分批执行（如
DELETE FROM t WHERE id BETWEEN ? AND ?），每次控制在5000行以内 - 确认事务隔离级别——
REPEATABLE READ下会锁住所有扫描到的间隙，可能阻塞并发插入 - 如果表有
BEFORE DELETE触发器，DELETE是唯一能激活它的命令
TRUNCATE 适合快速清空整表且不关心事务与触发器
TRUNCATE TABLE 是DDL操作，直接释放数据页，不走行级逻辑，也不记录单行日志。它快、省资源，但不可逆。
容易踩的坑：对有外键引用的表执行 TRUNCATE 会直接报错 ERROR 1701 (HY000): Cannot truncate a table referenced in a foreign key constraint；在事务中执行会被隐式提交，后续 ROLLBACK 无效。
- 仅用于无外键依赖的表，或已提前禁用外键检查（
SET FOREIGN_KEY_CHECKS = 0） - 执行后
AUTO_INCREMENT计数器重置为1（或初始值），这点和DELETE有本质区别 - 不会触发任何触发器，也不受存储过程权限限制（只要用户有
DROP权限即可） - 不能在有活跃事务的会话中对同一表执行
TRUNCATE，否则会等待元数据锁超时
DROP 是彻底移除表结构，不是“清空”
DROP TABLE 删除的是表定义本身，包括.frm文件（MySQL 8.0前）、.ibd文件、索引、约束、触发器等全部元数据。它不是“删数据”，是“删对象”。
典型误操作：把 DROP 当成“更快的 TRUNCATE”来用，结果发现表没了，应用直接报错 Table 'db.t' doesn't exist；或在未备份情况下执行，恢复成本极高。
- 执行前务必确认该表没有被视图、存储过程、函数或事件引用，否则这些对象会变为
INVALID -
DROP不检查外键依赖——它会直接报错并中断，除非加CASCADE（MySQL 8.0.19+ 支持，但慎用） - 即使表很小，
DROP在InnoDB中仍需同步更新数据字典、释放表空间，可能引发短暂I/O毛刺 - 生产环境应严格限制账号的
DROP权限，普通开发账号不应拥有ALTER或DROP权限
真正决定选哪个的，其实是“你敢不敢承担后果”
DELETE 最安全但最慢，TRUNCATE 快但不可逆，DROP 最彻底但也最危险。很多线上事故不是因为不懂语法，而是没想清楚“删完之后，下游服务、监控告警、ETL任务、BI报表会不会崩”。
尤其注意：MySQL 8.0 的 atomic DDL 机制让 TRUNCATE 和 DROP 更可靠，但它们依然不进binlog事务流——主从复制里看不到中间状态，出问题只能靠备份恢复。
