truncate 会重置自增id且不支持where条件，是ddl操作，隐式提交事务、不触发触发器和级联删除；delete是dml操作，支持where和回滚，但不重置自增id。
TRUNCATE 会重置自增 ID，但不能带 WHERE 条件
直接执行 TRUNCATE TABLE user 就能清空整张表并把 auto_increment 计数器归零——这是它和 DELETE 最本质的区别。MySQL 内部会先删掉表再重建，所以不走逐行删除逻辑，也不触发 ON DELETE 级联或触发器。但正因为是 DDL 操作，它不支持加条件，TRUNCATE TABLE user WHERE status = 0 这种写法会报错 ERROR 1064。
常见错误现象：误以为 TRUNCATE 可以带条件，结果语法报错；或者在事务中使用，发现它会隐式提交当前事务（哪怕没写 COMMIT）。
- 仅适用于 MyISAM 和 InnoDB（InnoDB 下需确保表无外键引用）
- 执行后
SELECT LAST_INSERT_ID()返回 0，不是上一次插入的 ID - 不会记录每一行的删除日志，所以无法回滚（即使在事务块里）
DELETE 不重置自增 ID，但支持 WHERE 和事务回滚
DELETE FROM user 清空表后，下一条插入的 ID 会接着上次最大值继续（比如之前最大是 100，清空后新插入第一行 ID 是 101）。它走的是 DML 流程，每行都标记为“已删除”，会触发 DELETE 触发器，也受事务控制——ROLLBACK 能恢复数据。
性能差异明显：大表（百万级以上）用 DELETE 清空，可能卡住、锁表时间长，还容易撑爆 undo log；而 TRUNCATE 几乎是瞬间完成。
- 想保留部分数据？只能用
DELETE WHERE，TRUNCATE不行 - 需要审计日志或触发清理逻辑？选
DELETE，TRUNCATE绕过所有这些机制 - InnoDB 表若被其他表通过外键引用，
TRUNCATE直接失败，DELETE则取决于外键约束动作（如ON DELETE CASCADE）
RESET AUTO_INCREMENT 的替代方案：ALTER TABLE … AUTO_INCREMENT
如果已经用了 DELETE 清空表，但又想重置自增起点，可以单独执行：ALTER TABLE user AUTO_INCREMENT = 1。注意这不是“重置当前值”，而是设置下一次插入时使用的起始值；如果表里还有数据，该语句会自动取当前最大 ID + 1 和你指定值的较大者。
容易踩的坑：ALTER TABLE user AUTO_INCREMENT = 0 在 InnoDB 中会被强制转成 1；而 ALTER TABLE user AUTO_INCREMENT = 100 如果表里已有 ID=150 的行，实际生效值仍是 151。
- 必须有
ALTER权限 - 执行期间会锁表（尤其在大表上），建议低峰期操作
- 不推荐在从库上直接执行，可能引发主从不一致
真正要快，还得看存储引擎和表结构
TRUNCATE 快的本质，是跳过了 InnoDB 的行级事务管理开销。但如果表上有全文索引（FULLTEXT）、空间索引（SPATIAL）或大量二级索引，TRUNCATE 重建表的过程也会变慢。MyISAM 表 TRUNCATE 极快，但 InnoDB 大表首次 TRUNCATE 可能因 buffer pool 刷脏页延迟几秒。
更隐蔽的问题：某些云数据库（如阿里云 RDS MySQL）对 TRUNCATE 做了权限限制，默认禁止；而 DELETE 即使没 DROP 权限也能执行（只要用户有 DELETE 权）。
- 确认引擎：
SHOW CREATE TABLE user查ENGINE=InnoDB还是MyISAM - 检查外键：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'user' AND REFERENCED_TABLE_NAME IS NOT NULL - 线上环境优先测
TRUNCATE是否被策略拦截，别等发布时才发现权限不够
