delete是dml操作，逐行删除、可回滚、支持where条件、触发触发器；truncate是ddl操作，清空全表、不可回滚、重置自增、不触发触发器、立即释放空间。
DELETE 是逐行 DML 操作，必须走事务日志
DELETE 本质是数据操作语言（DML），每删一行，MySQL 就往 undo log 里记一条反向记录，同时在 redo log 中写入页变更。这意味着：
- 即使不显式写 BEGIN，在 autocommit=1 时，每条 DELETE 也自动成一个独立事务
- 带 WHERE 条件时，InnoDB 会加行级锁（RECORD LOCK 或 GAP LOCK），可能引发锁等待甚至死锁
- 大表全删（DELETE FROM t）会撑满 undo tablespace，尤其在 long-running 事务未提交时，容易报 ERROR 1205 (HY000): Deadlock found 或 ERROR 1213 (40001)
- 触发器（BEFORE/AFTER DELETE）会被执行，外键约束也会被逐条校验
TRUNCATE 是隐式 DDL，绕过事务系统直接重建段
TRUNCATE 不是“删除数据”，而是让 InnoDB 丢弃原表的 ibd 文件对应的数据段（segment），再新建一个空段——相当于原子性地执行了“删文件 + 重建结构”。因此：
- 它不写 undo log，也不进事务日志队列，所以 ROLLBACK 无效，执行即生效
- 不触发任何 DELETE 触发器，也不检查外键引用（若表被其他表的外键引用，TRUNCATE TABLE t 会直接报错 ERROR 1701 (HY000)）
- 自增计数器（auto_increment）强制重置为 1（InnoDB 和 MyISAM 均如此）
- 表的 high water mark 彻底归零，后续 SELECT 扫描范围变小，EXPLAIN 显示的 rows 估算值更准
权限、锁与执行时机的硬性差异
两者在权限模型和锁行为上完全不同，不是“快慢”问题，而是“能不能做”的问题：
- DELETE 需要 DELETE 权限；TRUNCATE 需要 DROP 权限（因为 DDL 语义上等价于“删表再建表”）
- DELETE 在执行中持有 IX（意向排他）锁 + 行锁，其他会话仍可读（MVCC 可见），但写同主键/唯一键会阻塞
- TRUNCATE 会先获取表级 SCH_M（schema modification）锁，期间整个表不可读不可写，哪怕只有一行数据也要等锁释放
- 在 GTID 模式下，TRUNCATE 是安全的；但 CREATE TABLE ... SELECT 类语句会被拒绝，而 TRUNCATE 不受影响
别在事务里用 TRUNCATE，也别指望它支持 WHERE
这是最常踩的两个坑：
- 在 BEGIN 后执行 TRUNCATE TABLE t，MySQL 会**自动提交当前事务**（隐式 commit），接着才执行 truncate —— 所以你后面跟 ROLLBACK 已经没用了
- TRUNCATE TABLE t WHERE id > 100 是语法错误，MySQL 直接报 ERROR 1064 (42000)，它根本不解析 WHERE 子句
- 如果你真需要“条件清空 + 快速释放空间”，只能分两步：DELETE 带条件删掉大部分，再用 OPTIMIZE TABLE t 收缩碎片（但 OPTIMIZE 本身也是 DDL，会锁表）
