在MySQL日常数据维护中，DELETE语句承担着按条件清除无效记录的职责。它和DROP、TRUNCATE不同，属于数据操作语言，删除动作记录在事务日志里，允许回滚。搞清楚它的执行逻辑，是避免误删和性能故障的第一步。
一、DELETE语句的基础语法与执行原理
标准DELETE语法由DELETE FROM、表名、WHERE条件以及可选的ORDER BY和LIMIT组成。数据库引擎在处理时，先根据WHERE条件扫描符合条件的行，对每行加行锁，再将旧值写入undo日志，最后从聚簇索引和二级索引中移除指针。这意味着即使只删除一行，若WHERE字段无索引，也会触发表全扫描。
下面是一个最基本的有条件删除示例，删除指定用户三天前的操作日志：
DELETE FROM user_log WHERE user_id = 1024 AND create_time < DATE_SUB(NOW(), INTERVAL 3 DAY);
如果省略WHERE子句，MySQL会删除表中所有行，但表结构、自增计数器与权限保持不变。此时事务未提交前可用ROLLBACK撤销，一旦提交便只能依赖备份恢复。因此在编写脚本时，应当把WHERE视为必填项而非可选项。
从执行计划角度看，使用EXPLAIN观察DELETE语句十分必要。当type列显示为ALL，说明进行了全表扫描，对于百万级大表这将产生大量undo日志与长时间锁持有，极易阻塞业务写入。合理的做法是确保WHERE条件命中索引，让type至少为range或ref。
二、防止误删与生产环境安全护栏
很多线上事故源于自动化脚本或人工客户端中漏写条件。建立安全护栏比依赖个人细心更可靠。第一类护栏是在连接会话层面开启SQL_SAFE_UPDATES，该模式禁止无WHERE或WHERE无索引的DELETE与UPDATE执行。
开启方式非常简单，在会话或全局配置中设置即可：
SET sql_safe_updates = 1; -- 此后执行无索引条件的删除会被拒绝 DELETE FROM user_log WHERE 1=1; -- ERROR 1175: You are using safe update mode
第二类护栏是先用SELECT核对影响行数。任何DELETE前，先以相同WHERE执行SELECT COUNT(*)确认范围。若数量异常偏大，应暂停并复查条件。第三类护栏是采用软删除，即在表中增加is_deleted字段，业务查询过滤该字段，物理删除延后到低频维护窗口批量处理，这样即便逻辑出错也能通过反转标记恢复。
对于必须物理删除的场景，建议封装存储过程并加入事务与审计日志。在事务中执行删除，成功后写入操作记录表再提交，失败则回滚。这样既能追溯谁删了什么，也降低了单次误操作不可恢复的风险。
三、大表批量删除与性能优化策略
当需清理千万级历史数据时，一次性DELETE会造成事务过长、锁表与从库延迟。正确思路是切分为小批次循环删除，每批几百到几千行，批间短暂休眠释放锁与日志压力。
以下示例展示以主键范围分批删除的存储过程逻辑：
DELIMITER //
CREATE PROCEDURE batch_delete_log()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE min_id INT;
WHILE NOT done DO
SELECT MIN(id) INTO min_id FROM user_log
WHERE create_time < '2023-01-01' LIMIT 1;
IF min_id IS NULL THEN
SET done = 1;
ELSE
DELETE FROM user_log
WHERE id BETWEEN min_id AND min_id + 999;
DO SLEEP(1);
END IF;
END WHILE;
END //
DELIMITER ;
除了分批，还应关注索引维护成本。带二级索引的表删除行时，引擎需同步更新多个索引树，批量越大随机IO越高。若业务允许，可临时暂停非必要索引，删除完成后再重建。另外，对于纯日志类无业务关联的大表，若无需按条件保留部分数据，TRUNCATE在速度上远优于DELETE，但它是DDL且无法回滚，选择前必须确认无需事务保护。
主从架构下，大事务DELETE会在binlog中以行格式或语句格式同步，造成从库应用延迟。采用ROW格式虽安全但日志量大，可结合分批提交控制单事务尺寸。监控show slave status中的Seconds_Behind_Master指标，确保删除任务不会拖垮读副本。
四、DELETE与其他删除方式的对比选择
除了DELETE，MySQL还提供TRUNCATE TABLE与DROP TABLE。DROP直接移除表结构与数据文件，适用废弃表；TRUNCATE重置表到初始状态，释放空间且不支持WHERE；DELETE则最灵活但最慢。理解差异才能选对工具。
通过下方对照可快速判断使用场景：
| 方式 | 语言类型 | 可否带条件 | 可否回滚 | 速度 |
|---|---|---|---|---|
| DELETE | DML | 是 | 是（事务内） | 慢 |
| TRUNCATE | DDL | 否 | 否 | 快 |
| DROP | DDL | 否 | 否 | 最快 |
实际项目中，临时表清理可用TRUNCATE，核心业务表误删风险高必须坚持DELETE加事务。若使用ORM框架，也要注意其生成的DELETE语句是否带了正确条件，避免上层对象状态错误导致全表删除。在代码层面对危险操作加二次确认，是工程规范的最后防线。