TRUNCATE 和 DELETE 的执行效果差异
TRUNCATE 会彻底清空表数据并重置自增主键计数器，DELETE 则逐行删除，不重置
AUTO_INCREMENT值（除非显式
ALTER TABLE ... AUTO_INCREMENT = 1）。这意味着：如果表里原来有 1000 条记录、
AUTO_INCREMENT已到 1001，执行
TRUNCATE后下一条插入的 ID 是 1；而
DELETE FROM table后下一条插入的 ID 是 1001。
TRUNCATE 无法带 WHERE 条件，DELETE 可以
TRUNCATE是 DDL 操作，语法上不支持
WHERE子句，只能清空整张表。而
DELETE是 DML，支持完整条件过滤：
DELETE FROM users WHERE status = 'inactive';
常见误操作：把
DELETE FROM users;写成
TRUNCATE users;看似等价，但若后续依赖自增值连续性或触发器逻辑，行为完全不同。
事务与回滚能力不同
DELETE在事务中可回滚，
TRUNCATE多数 MySQL 存储引擎（如 InnoDB）下虽能回滚，但实际依赖于是否开启事务及 binlog 格式；更关键的是：
TRUNCATE会隐式提交当前事务，执行后无法再用
ROLLBACK撤销之前的操作。
DELETE：受事务控制，可配合
START TRANSACTION安全测试
TRUNCATE：发出即生效，即使在事务块内，也会立即释放页空间、重建表结构 MyISAM 表上
TRUNCATE不支持回滚，InnoDB 表上虽可回滚，但代价高、不推荐依赖
权限、触发器与锁机制区别
TRUNCATE需要
DROP权限（而非
DELETE权限），且不会触发
ON DELETE触发器；
DELETE则会正常激活所有定义的行级触发器。
锁表现也不同：
DELETE对每行加行锁，可能引发锁等待或死锁，尤其大表未加索引的 WHERE 条件
TRUNCATE加的是表级元数据锁（
META DATA LOCK），阻塞其他 DDL，但不与普通 SELECT 冲突（除非显式
LOCK TABLES）
TRUNCATE不写入 undo log，日志体积小；
DELETE会产生大量 undo 和 redo 日志，大表慎用
真正需要“快速清空+重置自增+无触发逻辑”的场景才选
TRUNCATE；只要涉及条件、审计、触发器或需事务包裹，就只能用
DELETE。别因为
TRUNCATE快就默认替换
DELETE—— 自增 ID 跳变和权限报错
ERROR 1142 (42000): TRUNCATE command denied是线上最常被忽略的两个坑。
