TRUNCATE 比 DELETE 快但无条件、不走事务、不触发触发器；DELETE 虽慢但支持条件筛选、事务回滚和触发器，适用于按时间等条件清理数据的场景。
DELETE 比 TRUNCATE 慢，但能加条件、走事务、触发触发器
直接删全表用 TRUNCATE 看似快，但多数“清旧数据”场景根本不能用它——比如只删 2022 年前的订单、保留最近 90 天日志。这时候必须用 DELETE，否则逻辑就错了。
常见错误现象：DELETE FROM logs WHERE created_at 在大表上卡住、锁表、拖慢线上查询。
- 务必在
created_at字段上有索引，否则全表扫描 + 锁行 = 雪崩 - 别一次性删几百万行，分批删：
DELETE FROM logs WHERE created_at ，循环执行 - 确认没开启
AUTOCOMMIT=1，否则每删一批都自动提交，binlog 膨胀、主从延迟加剧 - 如果表有
ON DELETE CASCADE或触发器，TRUNCATE会绕过它们，DELETE才会触发
TRUNCATE 不能回滚、不走 binlog（ROW 格式下）、会重置自增 ID
TRUNCATE TABLE old_backup 是 DDL 操作，不是 DML，这点和直觉相反。它快，但代价明确：事务里执行也立刻生效，ROLLBACK 无效；MySQL 8.0+ 的 ROW 格式 binlog 里甚至不记录具体删除了哪些行。
使用场景仅限：确认要清空整张表、不需要审计痕迹、不依赖当前自增值连续性、无外键引用该表（否则报错）。
-
TRUNCATE会重置AUTO_INCREMENT计数器，哪怕你刚插入过 100 万条再 truncate，下次 insert 从 1 开始 - 如果表被其他表用
FOREIGN KEY引用，TRUNCATE直接失败，得先删外键或改用DELETE - 某些云数据库（如阿里云 RDS）对
TRUNCATE做了权限隔离，普通账号可能无权执行
WHERE 条件写错导致误删——这是最常发生的生产事故
删数据前没验证条件，或者时间字段类型理解错，一条命令下去整个业务表空了。这不是危言耸听，是 DBA 接到的第一个电话常因这个。
- 执行前一定先
SELECT COUNT(*) FROM table WHERE ...看数量是否符合预期 - 注意时间字段类型：
DATETIME和TIMESTAMP在时区处理上不同，NOW()和SYSDATE()行为也不同 - 避免用函数包裹索引字段：
WHERE DATE(created_at) 会让索引失效，改用 <code>created_at - 测试环境跑完，上线前再在预发库用
EXPLAIN确认执行计划走了预期索引
大表删数据后空间没释放？InnoDB 文件不会自动收缩
删完几千万行，du -sh /var/lib/mysql/db/table.ibd 还是那么大——因为 InnoDB 把空间记在内部空闲链表里，留给后续 insert 复用，不还给文件系统。
- 想真正缩文件，只能
OPTIMIZE TABLE table_name（MySQL 5.7）或ALTER TABLE table_name ENGINE=InnoDB（8.0 推荐），但会锁表、IO 高 - 如果用的是共享表空间（
innodb_file_per_table=OFF），删数据根本不会减小 ibdata1，此时只能重建实例 - 日常运维建议打开
innodb_file_per_table=ON，单表操作不影响全局
真正麻烦的从来不是语法对不对，而是删之前没看执行计划、没估量影响行数、没确认备份是否有效。这些地方一漏，后面就是通宵救火。
