InnoDB的DELETE仅逻辑标记删除行，不物理擦除或缩文件，故磁盘空间不释放；真正释放需OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表，但须满足innodb_file_per_table=ON、无长事务阻塞purge、足够磁盘冗余等前提。
DELETE 为什么删完表还占着磁盘空间
在 InnoDB 引擎下，DELETE 不是真的擦除数据，而是给行打上“已删除”标记，后续插入可复用这部分空间，但磁盘文件大小不会自动缩小。这导致你执行 DELETE FROM user; 后，information_schema.tables 里查到的 DATA_LENGTH 几乎不变。
常见错误现象：清空大表后磁盘使用率没降，误以为删失败了。
- 带
WHERE条件的DELETE一定不释放空间 - 全表
DELETE在 MyISAM 中会立刻释放空间，在 InnoDB 中不会 - 想真正收缩文件，得补一句
OPTIMIZE TABLE user;（注意：该操作会锁表） - 事务中执行
DELETE，未COMMIT前可ROLLBACK；一旦提交，就只能靠备份恢复
TRUNCATE 为什么不能加 WHERE 且一执行就不可逆
TRUNCATE TABLE user; 实质是“新建一个空表结构 + 删除原表”，属于 DDL 操作，不走事务、不记 undo 日志、不触发触发器。它快，是因为跳过了逐行扫描和日志记录。
使用场景很明确：你要彻底清空一张表，且不需要条件过滤、不关心回滚、不怕自增 ID 重置。
- 执行后
AUTO_INCREMENT计数器归零（或回到CREATE TABLE时定义的AUTO_INCREMENT = N值） - 外键约束存在时，
TRUNCATE会失败（ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint），而DELETE可以配合SET FOREIGN_KEY_CHECKS = 0;绕过 - 不能写成
TRUNCATE TABLE user WHERE id > 100;—— 语法直接报错，MySQL 不支持
DROP 为什么执行后连表名都查不到
DROP TABLE user; 不只是删数据，而是把表定义、索引、触发器、权限关联全部抹掉。元数据从 information_schema.TABLES 中消失，物理文件（如 user.ibd）被移除，InnoDB 字典里也清除对应条目。
容易踩的坑在于：开发环境随手 DROP 测试表没问题，但生产库一旦执行，连 SHOW CREATE TABLE user; 都报 ERROR 1146 (42S02): Table 'db.user' doesn't exist。
- 即使表刚被
CREATE出来，DROP也不需要确认，无交互、无提示 -
DROP TEMPORARY TABLE只影响当前会话的临时表，不影响普通表 - 如果依赖该表的视图或存储过程还存在，它们会变成无效状态（
INVALID），调用时报错
选哪个？关键看三个动作是否允许
别记口诀，盯住你手里的需求 checklist：
- 要保留表结构和字段定义？→ 排除
DROP - 要按条件删部分数据？→ 只能用
DELETE - 要立刻释放磁盘空间且不怕自增重置？→
TRUNCATE是最快解，但确认没外键引用 - 敢不敢承担“删完即失”的风险？→
TRUNCATE和DROP都不进 binlog 回滚点，备份链断了就真没了
最常被忽略的是外键和事务隔离级别：在 READ COMMITTED 或更低级别下，DELETE 的性能可能比预期差很多；而 TRUNCATE 在有外键依赖的 schema 里根本跑不通——这点上线前必须验证。
