MySQL中UPDATE和DELETE语句的执行并非直接修改或删除数据，而是需要经过一系列标准化的处理流程，同时合理的优化可以大幅提升这两条语句的执行效率，降低对线上业务的影响。
一、UPDATE语句执行流程
1. 语句解析与权限校验
MySQL接收到UPDATE语句后，首先由解析器对语句进行词法和语法分析，检查语句是否符合SQL规范，之后查询权限模块校验当前用户是否拥有目标表的UPDATE权限，若权限不足则直接返回错误。
2. 查询优化与执行计划生成
优化器会根据表的统计信息、索引情况生成最优的执行计划，决定使用哪个索引定位需要修改的记录，避免全表扫描。如果表没有合适的索引，优化器可能选择全表扫描，这会大幅提升语句的执行耗时。
3. 记录定位与加锁
存储引擎根据执行计划定位到符合条件的记录，对目标记录加行锁（InnoDB引擎默认行锁，无索引时会升级为表锁），同时记录修改前的旧值到undo log中，用于事务回滚和MVCC多版本控制。
4. 数据修改与日志写入
修改记录的对应字段值，更新记录的事务ID和回滚指针，之后将修改操作写入redo log buffer，事务提交时redo log会刷入磁盘，保证数据的持久性。如果是开启binlog的场景，修改操作还会写入binlog日志。
5. 事务提交与锁释放
事务提交后，redo log和binlog完成刷盘，之后释放目标记录上的锁，其他事务可以访问修改后的记录。
二、DELETE语句执行流程
DELETE语句的执行流程和UPDATE大体相似，仅在数据修改环节有区别：
- 解析、权限校验、优化、加锁环节和UPDATE完全一致
- 数据修改环节不会真正删除磁盘上的记录，而是将记录的删除标记位设置为已删除，同时记录旧值到undo log
- 后续由purge线程在合适的时机清理被标记为删除的记录，释放存储空间
三、UPDATE与DELETE语句优化方法
1. 添加合适索引
两条语句的WHERE条件字段尽量添加索引，避免全表扫描导致的长耗时和表锁风险。例如用户表需要根据手机号更新用户状态，给手机号字段添加普通索引：
-- 添加索引示例 ALTER TABLE user ADD INDEX idx_phone (phone); -- 带索引的UPDATE语句，执行效率更高 UPDATE user SET status = 1 WHERE phone = '13800138000';
2. 控制批量操作的数据量
避免一次性更新或删除大量数据，大批量操作会导致事务过长、锁占用时间久，甚至引发主从延迟。可以将大操作拆分为小批次执行：
-- 分批次删除示例，每次删除1000条 DELETE FROM order_table WHERE create_time < '2023-01-01' LIMIT 1000;
3. 避免无WHERE条件的操作
严禁执行没有WHERE条件的UPDATE和DELETE语句，这类语句会修改或删除全表数据，造成不可挽回的数据损失。如果必须全表操作，先通过SELECT语句确认影响范围：
-- 先确认影响行数 SELECT COUNT(*) FROM user WHERE status = 0; -- 确认无误后再执行更新 UPDATE user SET status = 1 WHERE status = 0;
4. 合理设置事务隔离级别
如果业务对一致性要求不高，可以适当降低事务隔离级别，减少间隙锁的范围，降低锁冲突的概率。但要注意隔离级别的调整需要符合业务的数据一致性要求，不能随意修改。
5. 及时提交事务
避免长事务占用锁资源，执行完UPDATE或DELETE语句后及时提交事务，减少锁的持有时间，降低对其他业务请求的影响。
四、注意事项
执行UPDATE和DELETE语句前一定要先备份相关数据，避免误操作导致数据丢失。线上环境执行大批量操作前，建议先在测试环境验证执行计划和耗时，再在低峰期执行。
提示：InnoDB引擎下，UPDATE和DELETE操作都会产生undo log，如果操作数据量过大，可能导致undo表空间膨胀，需要定期关注undo表空间的使用情况。
对于频繁执行更新删除操作的表，可以定期清理碎片，优化表的存储结构，提升后续操作的执行效率。