MySQL DML核心指南：INSERT、UPDATE、DELETE的语法、原理与避坑实战

做后端开发这些年，我最大的体会是：MySQL里最容易出事儿的，不是那些花里胡哨的查询，而是每天都在写的增删改。INSERT、UPDATE、DELETE这组DML（Data Manipulation Language，数据操作语言）语句，看似简单，但线上数据事故十有八九都是在这儿翻的车——要么UPDATE忘了带WHERE，要么DELETE没确认影响行数就执行，要么大批量INSERT撞上唯一键导致整个批次回滚。如果你正准备入行后端，或者在维护学生成绩、课程信息这类带明确实体关系的表结构，这篇文章就是按DML的核心脉络帮你把地基夯实。我不会讲MySQL怎么安装配置，那些教程一搜一大把；我只讲DML本身：每条语句的标准语法、执行时数据库内部发生了什么、以及我在实际项目中验证过的操作习惯和避坑经验。面试问DML、日常开发写DML、线上排查DML问题，看这一篇基本够用。

1. 先把DML的边界划清楚：它管什么、在哪一层生效

1.1 SQL四大分类里，DML占了半壁江山

SQL语句通常被分成四类：DDL（数据定义语言）、DML（数据操作语言）、DQL（数据查询语言）、DCL（数据控制语言）。DML的核心成员就是INSERT、UPDATE、DELETE三个，它们的作用对象是表里的"数据行"。

顺便说一个容易混淆的点：MySQL官方手册在讲DML时，实际上把SELECT的完整语法也放进了同一章。很多培训课程沿用这个习惯，会把SELECT算进DML。但从职责上讲，SELECT是查询、不修改数据，严格来说应该归为DQL。我个人更倾向于按"是否改变数据内容"来区分：改数据的是DML，查数据的是DQL。不过在后面的内容里，我会大量用到SELECT来配合DML操作——因为"先查后改"本来就是生产环境里必须养成的习惯。

DML和DDL的边界也要清楚。DDL操作的是表结构，比如CREATE TABLE、ALTER TABLE、DROP TABLE，这些语句一执行，表的结构就变了；而DML操作的是表数据，不管表里有多少行、结构多复杂，INSERT、UPDATE、DELETE都只关心"行"本身。结构定义和数据操作是两套逻辑，做数据库设计和开发的时候，心里要始终绷着这根弦。

1.2 一条DML语句在MySQL内部是怎么走完的

理解DML的底层逻辑，比死记硬背语法更有价值。一条DML语句从客户端发出到真正落盘，大致要经过这么几个阶段：

• 连接器：验证账号密码，获取当前用户的表权限。这里注意，MySQL的权限是在执行阶段才真正校验的，这也是为什么有时候刚赋完权限还要重新连接。
• 分析器：做词法分析和语法分析，检查你的SQL写没写错，表名、字段名是否存在。
• 优化器：决定用哪个索引、以什么顺序访问表。一条UPDATE语句的WHERE条件如果没走索引，优化器就会选择全表扫描。
• 执行器：调用存储引擎接口，真正去读数据、改数据。

对DML来说，最关键的是执行器阶段。InnoDB引擎在执行一条UPDATE时，并不是直接改磁盘上的数据，而是先把满足条件的行从索引里找到，加锁，然后在内存中修改，同时记录redo log和undo log。这就是为什么InnoDB能支持事务回滚——因为它把修改前的旧值写进了undo log，需要回滚时可以反向恢复。

还有一个概念值得记住：UPDATE和DELETE在InnoDB里是"先查后改"的两阶段操作。也就是说，哪怕你只改一行，MySQL内部也是先定位到那一行，再执行修改。所以WHERE条件能不能走索引，直接决定了这条语句是锁一行还是锁全表。这个细节后面讲锁的时候会重点展开。

1.3 DML执行完没提交，数据到底去哪了

很多初学者有个误区：执行完一条UPDATE，看到客户端返回了"Query OK"，就认为数据已经写进磁盘了。实际上，在MySQL默认的autocommit模式下，单条DML语句会自动开启事务并提交，所以看起来是"立即生效"。但如果你手动关闭了autocommit，或者用START TRANSACTION开启了事务，那么DML执行后数据只存在内存和redo log buffer中，还没有真正提交。

这条未提交的数据，当前会话自己能查到，但其他会话查不到（在默认的REPEATABLE READ隔离级别下）。如果这时候执行COMMIT，数据正式生效；执行ROLLBACK，则全部撤销。理解这个机制很重要，因为线上好多"误操作急救"都是靠它在最后关头挽回的——只要没提交，就还有回旋余地。

2. INSERT插入数据：从单行写入到批量优化的完整链路

2.1 三种INSERT写法和它们各自的适用场景

INSERT是DML里最基础的一句，但写法的选择会影响性能和数据安全。

先看最基础的完整写法：

sql复制INSERT INTO student (id, name, score, class_id) VALUES (1, '张三', 85, 101);

这里指定了字段列表和对应的值。我建议任何时候都显式写出字段列表，而不是省略。原因有两个：一是表结构在后续迭代中大概率会加字段，省略字段列表的写法在加字段后就会报错；二是SQL的可读性会大打折扣，别人接手时不看表结构根本不知道你插的是什么。

第二种是多行插入：

sql复制INSERT INTO student (id, name, score, class_id) VALUES 
(1, '张三', 85, 101),
(2, '李四', 90, 101),
(3, '王五', 78, 102);

一次INSERT语句插入多行，看起来只是少写了几条语句，实际效果却差很多。每条INSERT语句都有独立的SQL解析、网络传输和日志记录开销，多行合并成一条后，重做日志的刷盘次数大幅减少。我实测过，在普通机械硬盘的环境下，一次插100行比插100次单行快了5到10倍。这个差距在数据量上来之后非常可观。

第三种是INSERT INTO ... SELECT，从查询结果直接插入：

sql复制INSERT INTO student_archive (id, name, score, class_id)
SELECT id, name, score, class_id FROM student WHERE class_id = 101;

这种写法在表复制、数据归档、报表冷热分离场景里非常常用。比如学生毕业后，把他的成绩记录从主表挪到归档表，一条SQL就完成了"查+插"，不需要在应用层循环。

2.2 默认值、自增主键和NULL：INSERT时的隐式规则

INSERT时如果某个字段没出现在字段列表里，MySQL会优先用字段的默认值，没有默认值且允许NULL就用NULL，既没有默认值又不允许NULL就直接报错。所以设计表结构时养成好习惯：尽量给字段加DEFAULT，哪怕默认是0或空字符串，也能避免插入时踩到NOT NULL的坑。

自增主键（AUTO_INCREMENT）的场景更常见。插入时可以不写主键字段，由MySQL自动分配。但有一点很多人不知道：自增ID分配后即使事务回滚了，这个ID也不会复用。所以看到表里的自增主键出现空洞是正常的，别强迫症发作去"修复"它。

如果唯一键或主键冲突，INSERT默认会直接报错：

code复制ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'

处理冲突有两条常用路线。一种是INSERT IGNORE，冲突时自动忽略这条插入，不报错；另一种是INSERT ... ON DUPLICATE KEY UPDATE，冲突时改为执行更新逻辑。举个例子：

sql复制INSERT INTO student (id, name, score) VALUES (1, '张三', 90)
ON DUPLICATE KEY UPDATE score = VALUES(score);

这句话的意思很直白：主键冲突了？那就把这条记录的成绩更新成90。成绩单补录、Excel导入这类场景特别适合用这个语法，天然实现了"存在就更新，不存在就插入"的幂等操作。

2.3 大批量插入的优化思路：从几百行到几万行

做学生成绩批量录入、订单初始化这类需求时，经常会遇到一次性往表里灌几万条数据的场景。直接for循环逐条INSERT是最差的做法，效率低且容易触发锁竞争。我常用的优化手段有这几招：

第一，多行VALUES合并。前面说了，一次INSERT插几百行比插几百次快得多。注意单条SQL不要抄太大，我一般控制在500到1000行之间，否则SQL本身太长，binlog记录和网络传输都会成为瓶颈。

第二，关闭autocommit，分批次提交。在事务里循环插入，比如每500条COMMIT一次。这样既避免了每插一条就刷一次盘，又不会让事务太大导致undo log膨胀。

第三，插入前临时删除非必要的二级索引。索引在插入时需要同步维护，索引越多，插入越慢。批量导数据之前把不用的索引DROP掉，导完再重建，整个过程反而更快。不过这个操作要评估业务是否可接受短暂的无索引时间段。

第四，用LOAD DATA INFILE。如果数据源是文件，比如CSV，LOAD DATA的导入速度比INSERT快一个数量级，因为它的解析和写入路径经过了专门的优化。但使用前得先确保文件权限和安全配置，生产环境一般由DBA来控制。

批量插入时最怕的就是撞唯一键。默认情况下，InnoDB对一条INSERT语句是原子执行的——也就是说，多行VALUES里如果有一行撞了唯一键，整条语句的所有插入都会回滚，前功尽弃。这正是前面提到的INSERT IGNORE和ON DUPLICATE KEY UPDATE派上用场的时刻。

3. UPDATE更新数据：语法细节、锁机制和一次全表更新的"事故复盘"

3.1 UPDATE标准语法里，最容易被忽略的三个功能点

UPDATE的标准语法长这样：

sql复制UPDATE table_reference 
SET col1 = value1, col2 = value2 
[WHERE where_condition] 
[ORDER BY ...] 
[LIMIT row_count];

很多人写UPDATE只会用前两行，把WHERE、ORDER BY、LIMIT这三个可选子句完全忘在脑后。其实这三个子句在特定场景下很有价值。

先看SET部分。SET支持直接做算术运算，这就是很多人搜"mysql中int+5"时的真实需求。比如：期中考试成绩统一加5分。

sql复制UPDATE student SET score = score + 5 WHERE class_id = 101;

这里score = score + 5这种自更新的写法，在MySQL里非常常见，但要注意一个细节：如果score字段是INT类型，加完5分后超过INT上限，或者字段本身带符号限制，会报错。所以做数值运算前要确认字段类型和范围。

再讲WHERE。WHERE是UPDATE的安全阀，它的作用就是限定"改哪些行"。不加WHERE就等于告诉MySQL"把表里所有行都改了"——这是新手最容易犯的致命错误。所以我把WHERE叫作UPDATE的"安全带"，可以在任何人编写的UPDATE语句里检查第一件事。

然后是ORDER BY和LIMIT。这两个子句组合使用，可以实现"只更新排在最前面的N条记录"这种需求。比如把成绩最低的三个学生的分数统一加5分：

sql复制UPDATE student SET score = score + 5 ORDER BY score ASC LIMIT 3;

这种写法在Oracle、PostgreSQL里并不支持，是MySQL的一个特色功能，面试有时候会问，知道就行。

3.2 为什么UPDATE之前一定要先SELECT

我可以说，我在团队里定的第一条DML军规就是：UPDATE之前必须先执行同条件的SELECT。这不是小心过度，而是用真实事故换来的教训。

有一次同事要修改某个学生的基础信息，写的UPDATE条件没问题，但漏了一个班级ID的过滤条件。班里有个转班生，之前记录错分到了这个班，结果这位同学被连带改了资料。发现后我们只能通过binlog回溯原始数据去修复，耗时两个小时。

正确做法是这样：

sql复制-- 第一步：确认影响范围
SELECT id, name, score, class_id FROM student WHERE name = '张三' AND class_id = 101;

-- 第二步：确认无误后执行更新
UPDATE student SET score = 92 WHERE name = '张三' AND class_id = 101;

SELECT后返回的行数和内容，就是你UPDATE要动的东西。把SELECT的结果审视一遍，确认每一条都是要改的，然后再执行UPDATE。这个习惯成本极低，但能挡住90%的低级误操作。

另外，SQL客户端工具一般会显示执行后影响的行数，用ROW_COUNT()也能在语句执行后拿到这个值。如果UPDATE返回的影响行数和预期不一致，马上就能发现。

3.3 忘记WHERE之后的事故复盘：SQL_SAFE_UPDATES能救命

聊聊真实的翻车现场。有一次同事在测试环境清理数据，执行了这么一条SQL：

sql复制UPDATE student SET score = 90;

执行完才发现没写WHERE。如果这是生产环境，整张表的成绩都会被刷成90分，后果不堪设想。MySQL其实提供了一个安全防护机制——SQL_SAFE_UPDATES，但默认是关闭的。把它打开后，MySQL会拦截那些不带WHERE条件或者WHERE条件不带索引的UPDATE和DELETE语句：

sql复制SET SQL_SAFE_UPDATES = 1;

开启后，执行不带WHERE的UPDATE会直接报错：

code复制ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column.

我强烈建议所有开发环境都加上这个配置。它虽然会在某些合理场景（比如故意更新全表）下显得碍事，但比起偶尔手动关闭，能保住的次数要多得多。

3.4 UPDATE的锁机制：为什么"改一行"会锁住整张表

关于MySQL锁，这是面试高频、线上踩坑也高频的话题。简单说，InnoDB存储引擎的锁机制分为行锁和表锁两大类，UPDATE默认加的是行锁。但有个关键前提——WHERE条件必须能通过索引定位到具体行。

如果WHERE条件没走索引，MySQL扫描全表时发现满足条件的行就一一加锁，过程中会把扫描过的行全部锁住。在InnoDB的实现里，当扫描范围很大时，代价和表锁几乎没区别，所以常常表现为"一条UPDATE更新几行，最后锁住了一张表"。

举例说明：

sql复制-- 假设 class_id 上没有索引
UPDATE student SET score = score + 5 WHERE class_id = 101;

这条语句实际会扫描student表的所有行，并对每一行加锁，最终导致任何对其他行的DML操作都阻塞等待。这就是热搜词"mysql锁表"的成因之一。

此外，在REPEATABLE READ隔离级别下，InnoDB还会使用间隙锁（gap lock）和临键锁（next-key lock）。间隙锁锁的不是某一行，而是一个索引范围。你明明只UPDATE了id = 10这一行，但可能在id为8到15这个区间上加了间隙锁，导致id在范围内的其他行都无法插入。这种现象很难排查，因为从现象上看"我改了1行，为什么别的行都插不进去"。如果遇到这种问题，通常的解决思路是：检查WHERE条件是否走索引、是否在事务里执行了大量范围查询，以及是否可以通过调整事务隔离级别（比如改用READ COMMITTED）来减少间隙锁的影响。

3.5 多表UPDATE：JOIN更新和子查询更新的陷阱

实际业务里经常需要根据另一张表的数据来更新当前表。比如，学生表student里有个字段叫total_score，需要从成绩表score里汇总出来回填。这类需求有两种主流写法。

第一种是JOIN更新：

sql复制UPDATE student s
JOIN (SELECT student_id, SUM(score) AS total FROM score GROUP BY student_id) t
ON s.id = t.student_id
SET s.total_score = t.total;

第二种是子查询更新：

sql复制UPDATE student s
SET s.total_score = (SELECT SUM(score) FROM score WHERE student_id = s.id);

这两种写法都能实现需求，但有一个著名的坑：MySQL不允许在UPDATE的子查询中直接引用正在更新的目标表。比如下面的写法会报错：

sql复制-- 这行会报错：You can't specify target table 'student' for update in FROM clause
UPDATE student SET score = score + 1 WHERE id IN (SELECT id FROM student WHERE score < 60);

原因是MySQL的语法限制，不允许同时读取和写入同一张表。解决办法是套一层派生表包装：

sql复制UPDATE student SET score = score + 1 
WHERE id IN (SELECT id FROM (SELECT id FROM student WHERE score < 60) AS tmp);

这个坑在面试和实际开发中都很常见，一定要记住。

4. DELETE删除数据：语法细节、空间回收和高峰期大表删除的血泪教训

4.1 DELETE语法和不释放空间的真相

DELETE的语法比UPDATE更简单：

sql复制DELETE FROM table_name [WHERE condition] [ORDER BY ...] [LIMIT row_count];

它没有SET子句，只有"从哪张表、删哪些行"。同样地，DELETE不加WHERE就是把整张表的行全部删除，但表结构还在。这种操作需要格外谨慎。

一个常见的认知误区是：DELETE删掉的数据，表空间会立刻变小。实际上，在InnoDB里，DELETE并不会立刻把物理空间还给操作系统，它只是将记录标记为"已删除"，这些空间会由后台的purge线程异步清理，并可能被后续的INSERT复用。所以经常出现的情况是：你删了100万行，看了一眼磁盘占用，发现文件大小几乎没变。

在数据量大的生产表上，如果需要真正收缩表空间，通常要用OPTIMIZE TABLE或者ALTER TABLE ... ENGINE = InnoDB来重建表。但这类操作会在高峰期锁住表，影响在线业务，所以一般安排在维护窗口执行，需要先和DBA确认好时间窗口。

4.2 DELETE vs TRUNCATE：一张表说清区别

清理全表数据时，TRUNCATE和DELETE都能用，但它们有本质区别：

这里最容易误导人的是"TRUNCATE可以回滚"这个说法。在MySQL中，TRUNCATE TABLE被当作DDL语句处理，执行时会隐式提交当前事务，所以一旦执行就回不去了。DELETE是DML，放在事务里可以用ROLLBACK撤销。

所以如果只是清理测试数据、且需要保留表结构，可以放心用TRUNCATE；如果是在线业务表但要清空大部分数据，那就必须用DELETE分批处理，别指望TRUNCATE。

4.3 大表删除的正确姿势：分批DELETE而不是一把梭

假设你有一张日志表，积累了1亿行数据，需要删除其中半年前的旧记录。这种场景下，一条DELETE FROM log WHERE create_time < '2024-01-01'直接跑，会有几个严重问题：

• 一次删除千万行，事务巨大，undo log会急剧膨胀。
• 持有大量行锁，导致其他业务对该表的访问被阻塞。
• 主从复制场景下，超大事务会在从库回放很久，造成主从延迟。
• 如果中途报错或事务回滚，数据库可能长时间处于高负载状态。

正确做法是分批小量删除，类似这样：

sql复制DELETE FROM log WHERE id < 1000000 LIMIT 1000;

在应用层或者其他客户端循环执行上面这条语句，每次只删1000行，配合一定的休眠时间，给主从复制和purge线程留出喘息空间。如果表里没有现成的连续性ID，也可以用WHERE条件限定一个时间范围，一批一批推着删。

有些人觉得循环效率低，不如一把梭。但线上的核心原则不是"快"，而是"稳"。一次删除操作让数据库锁了一小时，远远比删十个小时更伤业务。

4.4 外键约束对DELETE的限制

如果父表记录被子表引用，直接DELETE父表数据会报错：

sql复制DELETE FROM student WHERE id = 1;

code复制ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails

这是外键约束在起作用。处理这类删除有三种策略：一是先删子表再删父表；二是在定义外键时加ON DELETE CASCADE，让MySQL自动级联删除；三是用ON DELETE SET NULL，把子表的外键字段置为NULL。具体选哪一种，取决于业务对数据完整性的要求。需要提醒的是，级联删除很方便，但也意味着一次DELETE可能悄悄删掉大量关联子表数据，使用之前一定要评估清楚影响范围。

5. 事务与DML的配合：回滚保护、批量提交和错误处理的容错方案

5.1 为什么说事务是DML的安全网

DML语句是事务操作的载体，而事务的ACID特性（原子性、一致性、隔离性、持久性）正是围绕DML的执行效果来保证的。原子性保证了INSERT、UPDATE、DELETE要么全部成功，要么全部回滚，不会出现"改了一半"的状态。

在MySQL里，默认的autocommit=1让每条DML语句自动提交。但在做多步骤的数据变更时，我更推荐显式开启事务：

sql复制START TRANSACTION;

UPDATE student SET score = 90 WHERE id = 1;
UPDATE class SET student_count = student_count + 1 WHERE id = 101;

COMMIT;

这样把多条DML放进一个事务里，中间任何一步出错，都可以直接ROLLBACK，回到事务开始前的状态。手动开启事务还有一个额外好处：你可以先执行DML，再执行SELECT验证结果，确认无误后再COMMIT。这个流程给了操作者一个"后悔药"窗口。

5.2 用了事务还是回滚不了？注意自动提交的陷阱

很多新手踩过这个坑：明明执行了START TRANSACTION，中间一条DML报错了，然后执行ROLLBACK，却发现之前成功的DML也一起被回滚了——这其实是预期行为。但如果是在默认autocommit=1模式下，每条DML都独立提交了，你再执行ROLLBACK当然没有效果，因为前面的事务已经结束了。

这里有个容易混淆的细节：InnoDB在执行一条UPDATE时，如果语句本身出错（比如字段值超范围），这条语句的所有修改会自动回滚；但如果语句执行成功、后面你手动ROLLBACK，那整条语句的修改才会被撤销。区分"语句级回滚"和"事务级回滚"，才能正确判断该不该ROLLBACK。

在多条DML组成的批量任务里，常需要部分成功、部分失败时做精细化处理，可以借助SAVEPOINT：

sql复制START TRANSACTION;

INSERT INTO student (id, name) VALUES (1, '张三');

SAVEPOINT sp1;

INSERT INTO student (id, name) VALUES (2, '李四');

-- 发现第二行有问题，回滚到sp1
ROLLBACK TO SAVEPOINT sp1;

COMMIT;

这个写法可以只回滚到某个保存点，保留之前的操作。批量导入时如果希望"跳过失败的行、保留成功的行"，配合INSERT IGNORE和SAVEPOINT能做到比较优雅的容错。

5.3 批量DML怎么提交才不拖垮数据库

批量操作最忌讳的是每个事务只有一行，也最忌讳一个事务包几十万行。前者频繁提交，刷盘压力大；后者单事务过大，锁持有时间长、回滚日志膨胀。我的经验是：批量提交按行数分事务，一般500到2000行一个事务比较均衡，具体取决于字段数量和平均行宽。

以学生成绩批量导入为例：

sql复制START TRANSACTION;

INSERT INTO score (student_id, course_id, score) VALUES
(1, 101, 85),
(2, 101, 90),
-- ... 中间约500行
(501, 101, 88);

COMMIT;

这种分块提交的方式，既避免了频繁提交的性能浪费，又控制了单事务的锁范围，对主从复制也友好。如果某一块失败了，只需要重试这一块，而不是重来全部数据。

6. 线上DML操作的几条军规——都是踩坑踩出来的

6.1 变更之前先备份，备份比经验更可靠

无论UPDATE还是DELETE，凡是影响线上数据的操作，第一条铁律就是先备份。最简单也最实用的一种备份方式：

sql复制CREATE TABLE student_bak_20250101 AS SELECT * FROM student WHERE class_id = 101;

这条语句把即将变动的数据原样复制到一个备份表里，一旦操作失误，可以从备份表恢复。它不需要停机，也不影响原表数据，成本很低。很多同事嫌麻烦不做，但真出事了才后悔——备份的几分钟，比事后靠binlog恢复几个小时要划算得多。

6.2 WHERE条件必须能走索引，否则宁可不执行

前面讲锁的时候提到，UPDATE和DELETE的WHERE条件不带索引，可能导致行锁升级为全表锁。还有一个更隐蔽的问题：不带索引的WHERE条件会触发全表扫描，数据量大时SQL执行时间会非常长，进一步加剧锁等待。

所以执行重要DML前，尤其是影响行数不确定的UPDATE/DELETE，建议先用EXPLAIN看一眼执行计划：

sql复制EXPLAIN SELECT id FROM student WHERE class_id = 101;

如果看到type = ALL，说明是全表扫描，需要认真考虑这个操作的影响范围。在开发环境强制自己养成这个习惯，到生产环境就不容易出大事故。

6.3 一条语句能完成的事，别分成多条循环

这个原则跟前面"批量DML分事务提交"不矛盾。很多人在应用层写循环去逐条更新，SQL就像这样：

python复制for student in students:
    cursor.execute("UPDATE student SET score = %s WHERE id = %s", (score, student_id))

几千个学生就是几千条UPDATE语句，网络往返、SQL解析、事务提交全都串行执行，性能和数据库资源占用都很差。如果更新的值是固定的（比如所有学生加5分），直接一条UPDATE搞定；如果每个学生的值不同，可以用CASE WHEN构造批量更新：

sql复制UPDATE student SET score = CASE id
    WHEN 1 THEN 85
    WHEN 2 THEN 90
    WHEN 3 THEN 78
END
WHERE id IN (1, 2, 3);

一条语句完成几十行、几百行的差异化更新，这在报表刷新、状态同步场景里几乎是必用技巧。

6.4 动态SQL拼接DML时，严防注入

无论自己写代码还是用ORM框架，只要DML语句里出现了字符串拼接，就要警惕注入风险。最典型的反面案例：

python复制sql = "DELETE FROM student WHERE name = '" + name + "'"

如果name的值是' OR '1'='1，这条SQL就会变成删除整张表：

sql复制DELETE FROM student WHERE name = '' OR '1'='1';

这种攻击手段太老套了，但依然有人中招。正确的做法是使用参数化查询：

python复制cursor.execute("DELETE FROM student WHERE name = %s", (name,))

参数化查询会让MySQL把传入值当作纯数据，而不是SQL语句的一部分，从根源上杜绝注入。任何涉及用户输入的DML，都要严格走这个路线。

6.5 高峰期不要执行大范围DML

最后一条经验是业务层面的：尽量把大批量数据变更安排到业务低峰期执行。所谓大批量，不只是DELETE几万行，也包括UPDATE一张大表的全部行、对在线表做结构变更后的数据回填等。白天业务高峰期，任何长时间持有锁的操作都会拖垮整个库的响应。

如果必须白天执行，就一定要拆批次、加SQL_SAFE_UPDATES保护、做好备份，并让DBA和值班同事知道变更窗口。提前在IM群里同步一句"我要执行XX操作，预计影响N行"，比到时候线上报警再排查要省心得多。

我自己这些年写DML，最大的心得是四个字：先查后改。再熟练的工程师，也免不了有手滑的时候。所有安全习惯——备份、SELECT确认、走索引、分批次——本质上都是给这个"手滑"兜底。DML语法本身不复杂，复杂的是在真实数据和并发压力下，让每一次数据变更都稳妥、可控、可回退。把这套习惯沉淀下来，以后无论面对的是几百行的小表，还是上亿行的核心业务表，你都能从容应对。