MySQL增删改查实战：从建库建表到锁表避坑全指南

凡是跟数据库打交道的朋友，永远绕不开四个字：增删改查。不管是刚接触MySQL的初学者，还是写了几年代码的老手，每天的工作本质上都是围绕这四类操作转的。我见过不少同学，理论背得头头是道，一到真环境就翻车——批量插入卡到怀疑人生，UPDATE忘了写WHERE把整张表的数据都改了，DELETE删完才发现没有备份。这篇东西不打算只丢几条语法给你，而是把增删改查从建库建表到实战操作，把我踩过的坑、总结出的经验一次性讲清楚。对刚入门的朋友来说，这是一条能直接照着操作的路径；对有基础的同学，也能帮你查漏补缺，看看有没有哪些细节疏忽了。

1. 建库建表时的三个关键选择

为什么讲增删改查之前要专门说建库建表？道理很简单：增删改查操作的对象是表里的数据，表结构没设计好，后面写再多的SQL都是给自己找不痛快。字段类型选错、字符集不对、主键策略混乱，这些问题会在你执行查询和更新的时候一一暴露出来，轻则性能慢，重则数据直接写不进去。所以这一节先把地基打牢。

1.1 环境准备：先有一个能跑的MySQL

在动手写SQL之前，你得先有一个能连上的MySQL实例。最简单的做法是去官方下载安装包装一个本地环境，或者如果你机器上已经装了Docker，一条命令就能拉起来：

bash复制docker run -d --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=yourpassword mysql:8.0

无论是哪种安装方式，装完之后都要确认服务在运行，然后通过客户端连上去。我个人的建议是：前期练习一定用命令行，不要一上来就开Navicat。命令行没有自动补全，没有图形化提示，所有语法都得自己手敲，恰恰是这种"不友好"能帮你最快记住语句结构。等你把常用语句都练熟了，再用图形化工具提升日常效率。

连接命令很简单：

bash复制mysql -uroot -p

连上之后先看下版本和环境：

sql复制SELECT VERSION();
SHOW DATABASES;

我第一次装MySQL的时候，最常遇到的问题就是服务启动不了，尤其是Windows环境下MySQL服务和相关配置项卡住。这类问题大部分是配置文件不一致或端口被占用导致的。排查思路别乱，先看错误日志，再确认3306端口是否被其他程序占用，最后检查配置文件里的路径和数据目录权限。环境这东西，装一次踩一次坑，踩完就记住了。

1.2 建库语句与字符集选择

建库的SQL很简单，但我强烈建议你养成一个习惯：库名、表名、字段名，全部用小写字母和下划线。虽然MySQL在Linux下对表名的大小写敏感，Windows下不敏感，这种差异本身就是坑，统一用小写从源头规避掉。

创建数据库的标准写法：

sql复制CREATE DATABASE IF NOT EXISTS demo
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_general_ci;

这里面最关键的就是 utf8mb4。我用过老项目里的 utf8，怎么说呢，平时存中文没什么问题，但一旦用户输入了表情符号，直接报错"Data too long for column"，因为真正的 utf8 在MySQL里最多只能存3个字节的字符，而emoji需要4个字节。utf8mb4 才是完整的UTF-8实现，现在新项目基本都用它。至于排序规则，utf8mb4_general_ci 是大小写不敏感的，适合绝大多数业务场景，如果你需要精确的大小写区分，再考虑 utf8mb4_bin 这类二进制排序规则。

1.3 建表：字段类型、约束和引擎

建一张用户表，这是练习增删改查时最常用也最好理解的例子。下面这张表覆盖了日常开发里大部分字段类型和约束的用法：

sql复制USE demo;

CREATE TABLE user (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
  username VARCHAR(50) NOT NULL COMMENT '用户名',
  password VARCHAR(255) NOT NULL COMMENT '密码',
  email VARCHAR(100) DEFAULT NULL COMMENT '邮箱',
  age TINYINT UNSIGNED DEFAULT 0 COMMENT '年龄',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1启用 0禁用',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

这张表里有几个点值得展开说。

主键用 INT UNSIGNED + AUTO_INCREMENT，这是最常见的主键策略。无符号整型把负数空间让给正数，能存的最大值翻倍。自增主键的好处是插入时不需要关注主键值，数据库自动分配，而且B+树对顺序插入的数据页管理更友好，不容易产生页分裂。

ON UPDATE CURRENT_TIMESTAMP 这个细节很多人会忽略。有了它，每次UPDATE这条记录时，update_time 字段会自动更新为当前时间，不用你在UPDATE语句里手动维护。这个习惯一旦养成，后续的排查和数据审计会省大量精力。

存储引擎选InnoDB，这个是默认也是几乎唯一的选择。早期项目里还能看到MyISAM，但它不支持事务、不支持行级锁，一旦发生并发写入，表锁会让整个表的操作串行化。热搜词里有个"mysql锁表"，大部分情况下指的就是MyISAM的表锁或者InnoDB下未提交事务导致的锁等待，后面专门讲。

2. INSERT插入数据：从单条到批量，再到乱码排查

表建好了，接下来就是往里塞数据。INSERT看起来是所有操作里最简单的，无非就是把值写进去，但实际使用中，批量插入怎么控制批次、主键冲突怎么处理、中文乱码怎么排查，这些问题几乎每个新手都会遇到。这一节把INSERT的完整使用场景拆开讲。

2.1 单条插入与批量插入的差异

单条插入，语法是固定的：

sql复制INSERT INTO user (username, password, email, age)
VALUES ('zhangsan', '123456', 'zhangsan@example.com', 25);

这是标准写法，字段列表明确指定了要插入的列，VALUES里按顺序给值。我强烈建议你显式写字段列表，而不是写 INSERT INTO user VALUES (...) 这种省略字段的写法。为什么？因为一旦表结构调整，新增了字段，省略写法的INSERT语句就全挂了，而显式写字段的语句完全不受影响。

真正拉开差距的是批量插入。一次插入多条记录，MySQL的语法是在VALUES后面用逗号分隔多条：

sql复制INSERT INTO user (username, password, email, age) VALUES
('lisi', '123456', 'lisi@example.com', 28),
('wangwu', '123456', 'wangwu@example.com', 30),
('zhaoliu', '123456', 'zhaoliu@example.com', 22);

批量插入相比逐条插入的性能提升是数量级的。原因有两层：第一，每一条INSERT和数据库之间的网络往返被省掉了；第二，InnoDB写入时产生的重做日志、二级索引更新等操作，合并成一次执行，整体开销小得多。

但批量也不是无脑越大越好。我自己测试下来，单批次在100条到500条之间比较合适。太少了体现不出批量优势，太多了事务日志会变得很大，而且一旦中间某条数据违反约束导致整个事务回滚，你就要重新来一遍。真实项目里导入大量数据时，一般用分批循环插入的方式，每批几百条，既稳定又不至于把数据库负载拉满。

2.2 默认值、NULL与空字符串

INSERT时有一个非常容易混的概念：默认值、NULL、空字符串。

先把三者区别说明白。默认值是在建表时用 DEFAULT 指定的值，INSERT时如果不传这个字段，数据库自动填默认值。NULL是SQL层面的"未知值"或"无值"。空字符串 '' 是一个真实存在的值，只是长度为0。

举个例子，前面的user表里 age 字段设了 DEFAULT 0，如果你插入时不传age：

sql复制INSERT INTO user (username, password, email) VALUES ('qiqi', '123456', 'qiqi@example.com');

查出来age就是0，这是默认值在起作用。那如果把age字段设计成 DEFAULT NULL 呢？不传的时候age就是NULL。

区别在哪？最大的坑在查询条件里。用 age = NULL 查不到任何数据，因为NULL不能用等号比较，必须用 IS NULL：

sql复制SELECT * FROM user WHERE age IS NULL;

这个错误我见过太多人犯了，甚至有工作两三年的同事还会在代码里写 WHERE age = null。本质上是因为在SQL里，NULL和任何值做比较，结果都是UNKNOWN，只有 IS NULL 和 IS NOT NULL 才真正判断NULL。

另一个实际问题是，写入数据时到底该用NULL还是空字符串？我的建议是：业务字段建议都用 DEFAULT NULL 表示"没有值"，不要用空字符串占位。因为NULL在统计函数（比如COUNT、AVG）里会被忽略，而空字符串会被当成一个有效值参与计算，这会直接影响统计结果的准确性。

2.3 主键冲突：ON DUPLICATE KEY UPDATE与INSERT IGNORE

业务里经常遇到这种场景：数据可能已经存在了，你要么想跳过它，要么想更新它。比如用户表里 username 有唯一索引，重复提交的时候直接INSERT会报错 Duplicate entry。

两种常见处理方式，语法都很好记：

方式一：INSERT IGNORE，冲突时静默跳过

sql复制INSERT IGNORE INTO user (username, password, email, age) VALUES ('lisi', '123456', 'lisi@example.com', 28);

如果username已经存在，这条语句不会报错，但也不会真正插入，只是被忽略掉。适合那种"不存在才插入，存在就算了"的场景。

方式二：ON DUPLICATE KEY UPDATE，冲突时执行更新

sql复制INSERT INTO user (username, password, email, age) VALUES ('lisi', '123456', 'new-email@example.com', 29)
ON DUPLICATE KEY UPDATE email = VALUES(email), age = VALUES(age);

它的含义是：如果唯一键或主键冲突了，就执行后面的UPDATE逻辑。VALUES(字段) 在UPDATE部分里引用的是本次INSERT试图写入的值。这个写法在同步数据、幂等写入的场景里非常实用。

但要注意，ON DUPLICATE KEY UPDATE在冲突时会走更新路径，这意味着它会占用自增ID，即使没有真正插入新记录，id序列也可能被跳过。如果业务里对ID的连续性有要求，这个行为要提前预期到。实际上自增ID出现空洞是很正常的，不用太纠结。

2.4 插入中文乱码的排查思路

中文乱码是新手期的高频问题，尤其是直接用命令行操作时。现象是插入中文后查出来变成 ???，或者直接报错。排查思路按顺序来：

第一步，确认表和库的字符集是不是utf8mb4。前面建表时已经指定了，但如果库不是utf8mb4，表会被库的默认字符集影响。

第二步，检查当前会话的字符集：

sql复制SHOW VARIABLES LIKE 'character_set%';

看 character_set_client 和 character_set_results 这两个变量的值。如果它们是utf8mb4，而你的客户端终端本身是GBK编码，就会产生乱码。

第三步，执行一条 SET NAMES utf8mb4; 再插入试试。这条命令会把客户端、连接、返回结果的字符集统一设置为utf8mb4。绝大多数命令行乱码问题，执行完这条就解决了。

现在很多图形化工具会自动处理连接字符集，所以乱码问题比早年少了。但一旦遇到，记住这个排查顺序，从表结构到连接层一层层查，别一上来就怀疑数据库装坏了。

3. SELECT查询：条件、聚合、联表，一口气讲透

SELECT是增删改查里使用频率最高、也最考验基本功的操作。前面INSERT的数据最终都是为了让SELECT能查出有价值的信息。很多人的SQL水平停留在"能查出数据就行"，对WHERE条件的执行顺序、聚合分组的细节、联表方式的选择理解不透，导致写出来的查询要么结果不对，要么性能波动很大。这一节把SELECT的常用子句和底层逻辑串一遍。

3.1 WHERE条件的核心写法与陷阱

最简单的查询，查出表中所有数据：

sql复制SELECT * FROM user;

但生产环境里我强烈不建议随便用 SELECT *，尤其表字段很多的时候。原因有两个：一是会查出大量你根本不需要的列，白白占网络带宽；二是如果后面要加索引覆盖优化，SELECT * 几乎无法命中覆盖索引。日常练习没问题，但写业务代码时尽量只列出你需要的字段：

sql复制SELECT id, username, email FROM user;

WHERE条件里，最基础的是比较运算：

sql复制-- 等值条件
SELECT * FROM user WHERE status = 1;

-- 范围条件
SELECT * FROM user WHERE age >= 25 AND age <= 35;

-- 枚举条件
SELECT * FROM user WHERE status IN (0, 1);

-- 区间条件
SELECT * FROM user WHERE age BETWEEN 20 AND 30;

这里有个细节：BETWEEN 是包含边界的，age BETWEEN 20 AND 30 等价于 age >= 20 AND age <= 30，不包括年龄等于30以外的任何值。如果你要的是左开右闭区间，还是老老实实用 > 和 <= 组合。

模糊查询是LIKE，两个通配符要记牢：% 匹配任意多个字符，_ 匹配单个字符。

sql复制-- 查所有姓张的用户
SELECT * FROM user WHERE username LIKE 'zhang%';

-- 查用户名长度为5个字符的用户
SELECT * FROM user WHERE username LIKE '_____';

LIKE的坑在于：前缀通配符会让索引失效。LIKE 'zhang%' 在用户名有索引的情况下，MySQL可以利用索引进行范围扫描；而 LIKE '%zhang%' 因为要从任意位置匹配，索引就帮不上忙了，只能全表扫描。数据量小的时候感觉不出来，一旦表里几百万条数据，这个差异就是毫秒和秒级的区别。业务里如果经常要做包含匹配，考虑引入全文索引或者外部搜索引擎，而不是靠LIKE硬扛。

3.2 排序、分页与去重

排序用ORDER BY，默认是升序ASC，降序要写DESC：

sql复制-- 按年龄降序，年龄相同按创建时间升序
SELECT id, username, age, create_time
FROM user
ORDER BY age DESC, create_time ASC;

ORDER BY的字段顺序有讲究：第一个排序字段是主导的，只有第一个字段值相同，第二个字段才有意义。所以如果业务上要"按部门排序，部门内按薪水排序"，两个字段都要写进ORDER BY，而不是期望数据库自动处理。

分页是LIMIT的标准用法：

sql复制SELECT id, username FROM user ORDER BY id LIMIT 10 OFFSET 20;

这条语句跳过20条，取10条，对应第3页（每页10条）。LIMIT后面还可以简写成 LIMIT 20, 10，注意这个写法里，第一个参数是偏移量，第二个是条数，和 LIMIT 10 OFFSET 20 是等价的。

但这里有个非常经典的性能问题：深分页。当你翻到很后面的时候，比如 LIMIT 1000000, 10，MySQL并不是直接从第100万条开始取，而是要先把前100万条都查出来，然后丢弃，再返回后面的10条。这个代价非常大。

常见优化方式是记录上一页最后一条数据的ID，下一页直接用ID做条件过滤：

sql复制-- 第一页
SELECT id, username FROM user ORDER BY id LIMIT 10;

-- 第二页：以上一页最后一条记录的id = 10 为起点
SELECT id, username FROM user WHERE id > 10 ORDER BY id LIMIT 10;

这样查询直接走主键索引，不管翻到多深的页，性能都是稳定的。

去重用DISTINCT：

sql复制SELECT DISTINCT status FROM user;

这个写法要注意的是：DISTINCT作用在后面所有列的组合上。SELECT DISTINCT status, age FROM user 去重的是 (status, age) 这个组合，而不是单独对status去重。很多人误以为DISTINCT只对第一个字段去重，这是个高频误解。

3.3 聚合函数与GROUP BY

聚合函数是把多条记录计算成一个值。最常用的有 COUNT、SUM、AVG、MAX、MIN：

sql复制-- 统计总用户数
SELECT COUNT(*) AS total FROM user;

-- 统计年龄大于20的用户数
SELECT COUNT(*) FROM user WHERE age > 20;

-- 平均年龄、最大年龄、最小年龄
SELECT AVG(age), MAX(age), MIN(age) FROM user;

-- 总年龄
SELECT SUM(age) FROM user;

这里有一个重要区别：COUNT(*) 和 COUNT(字段) 不一样。COUNT(*) 统计的是记录行数，COUNT(age) 统计的是age字段非NULL的记录数。如果age允许为空，这两者结果可能不同。前面我说字段尽量用NULL而不是空字符串，就是从这里体现出来的——用空字符串的话，COUNT(age)会把这个字段算进去，统计口径就乱了。

GROUP BY是配合聚合函数做分组的：

sql复制SELECT status, COUNT(*) AS cnt
FROM user
GROUP BY status;

这是查询每种状态下分别有多少用户。GROUP BY之后，SELECT子句里只能出现分组字段和聚合函数，这个规则要严格遵守。最常见的语法错误就是GROUP BY之后，SELECT里写了既不是分组字段又不是聚合函数的列，MySQL的ONLY_FULL_GROUP_BY模式会直接拒绝执行。

如果要对分组之后的结果做过滤，不能用WHERE，要用HAVING：

sql复制SELECT status, COUNT(*) AS cnt
FROM user
GROUP BY status
HAVING cnt > 1;

WHERE和HAVING的执行顺序不一样：WHERE是在分组之前对原始记录进行过滤，HAVING是在分组聚合之后对结果进行过滤。这个顺序决定了你的过滤条件应该写在哪。能下推到WHERE的，就不要写在HAVING里，因为先缩小数据量再做分组，性能会好不少。

3.4 联表查询：内连接与外连接

真实业务中，数据很少只存在一张表里。用户一张表、订单一张表、商品一张表，查询的时候经常要把多张表的数据拼在一起。这就是JOIN（连接）的用武之地。

内连接（INNER JOIN）只返回两边都匹配得上的记录：

sql复制SELECT u.id, u.username, o.order_no
FROM user u
INNER JOIN orders o ON u.id = o.user_id;

这条查询返回的是有订单的用户和他们的订单号。如果一个用户没有订单，那么这位用户不会出现在结果里。

左连接（LEFT JOIN）则是以左表为主，左表记录一定全部保留：

sql复制SELECT u.id, u.username, o.order_no
FROM user u
LEFT JOIN orders o ON u.id = o.user_id;

这条查询返回所有用户，用户即使没有订单，也会出现，只是 order_no 那一列是NULL。这个差异是INNER JOIN和LEFT JOIN最核心的区别，先搞清楚业务需求是"只要匹配到的"还是"要左表全部保留"，再选择JOIN类型。

关于JOIN的写法，我自己总结了两条经验：

第一，连接条件用ON，过滤条件用WHERE，语义要分清楚。有时候你会发现把过滤条件写到ON里和写到WHERE里结果不一样，这是JOIN类型配合过滤条件的经典陷阱。尤其是LEFT JOIN时，如果把右表的过滤条件写到WHERE里，会过滤掉左表中本应保留的记录，导致结果变成和内连接一样的效果。

第二，能多用JOIN就不要写子查询。子查询在某些场景下也能实现同样的结果，但可读性和性能通常不如JOIN直观。一个典型的例子是"查有订单的用户"，用子查询写法是 WHERE user_id IN (SELECT user_id FROM orders)，用JOIN写法更清晰，并且优化器对JOIN的执行计划通常掌控得更好。

4. UPDATE与DELETE：两个直接影响数据的操作怎么谨慎使用

INSERT是往表里加数据，SELECT是读数据，这两个操作出问题最多是报错，再不济查询慢一点，不会造成不可逆的后果。但UPDATE和DELETE不一样，它们直接修改和删除数据，一旦条件写错或者忘了写条件，轻则业务数据乱套，重则整张表的数据被清空。这一节我把这两个操作的语法、坑、以及我习惯的防护措施讲清楚。

4.1 UPDATE基础语法与字段运算

UPDATE的基础语法：

sql复制UPDATE user SET email = 'newemail@example.com' WHERE id = 1;

语义很清楚：把id等于1的那条记录的email字段更新为新值。SET后面可以同时更新多个字段：

sql复制UPDATE user
SET email = 'newemail@example.com', age = 30
WHERE id = 1;

这里有个更新多个字段时容易犯的错：SET子句后面的字段赋值是按顺序执行的，如果同一个字段被赋值两次，以最后一次为准。比如：

sql复制UPDATE user SET age = 30, age = age + 1 WHERE id = 1;

最后age的值是31，因为先赋值30，再执行 age = age + 1（此时age已经是30了，再加1）。虽然这种写法不常见，但面试和实际排错时会遇到，要能看懂。

UPDATE还支持结合其他字段做运算更新，这个用法在业务里非常普遍。比如给某个用户的年龄加1岁：

sql复制UPDATE user SET age = age + 1 WHERE username = 'zhangsan';

不需要先把age查出来再算好值传回去，直接在SQL里做自增运算，SQL引擎会自己完成读取和更新，也避免了并发下重复更新覆盖的问题。

4.2 忘写WHERE的后果与预防习惯

UPDATE和DELETE最危险的时刻，就是忘记写WHERE条件的那一刻。

sql复制UPDATE user SET age = 0;

这条语句会执行成功，但它的真实含义是：把user表里所有用户的年龄都改成0。很多线上事故就是这样的低级错误导致的。你以为自己加了条件，实际上条件写错了；或者写完条件，因为某种原因条件被注释掉了。

我在团队里推行过几条防止这类事故的习惯，现在分享出来，每一条都是实打实踩过坑换来的：

第一，执行UPDATE和DELETE前，先跑一条同条件的SELECT确认影响范围。

sql复制-- 先看会影响到谁
SELECT * FROM user WHERE username = 'zhangsan';

-- 确认无误后，再执行更新
UPDATE user SET age = age + 1 WHERE username = 'zhangsan';

这个习惯看起来多花了1秒，但能挡住99%的误操作。尤其在数据量大的表上，UPDATE执行得很快，等你反应过来已经来不及了。

第二，UPDATE和DELETE尽量放在事务里执行，先不COMMIT，确认后再提交。

sql复制BEGIN;
UPDATE user SET age = age + 1 WHERE username = 'zhangsan';
-- 检查受影响行数，确认没问题
COMMIT;
-- 有问题就 ROLLBACK;

在命令行里手动操作时，只要没提交，就还有后悔的余地。

第三，给MySQL设置sql_safe_updates模式。

sql复制SET sql_safe_updates = 1;

开启这个模式后，UPDATE和DELETE必须带WHERE条件或LIMIT子句，否则MySQL会直接拒绝执行。这在练习环境和工作中的测试库非常有用，能强制你养成写条件的习惯。

4.3 DELETE与TRUNCATE：清空表到底该用谁

DELETE的基础用法，按条件删除指定记录：

sql复制DELETE FROM user WHERE id = 5;

-- 删除年龄小于18岁的用户
DELETE FROM user WHERE age < 18;

DELETE和UPDATE一样，必须小心WHERE。如果执行 DELETE FROM user;，那意思就是清空整张表，不是清除某一条。

那如果业务上确实要清空整张表，用DELETE还是TRUNCATE？两者的区别非常明显，我把它们列成一张表方便对照：

什么时候用TRUNCATE？我总结下来就两种场景：一是测试环境要快速重置表数据；二是临时表用完要彻底清空。生产环境的正式表，我基本不用TRUNCATE，哪怕业务上要清空，我也更倾向于用 DELETE FROM 表名，配合事务，先删除再确认，确认无误后提交。

另外有一个非常常见的需求："我只想清空表，但保留表结构，自增ID要重置"。TRUNCATE一条语句满足，但如果你因为事务原因只能用DELETE，清空之后再执行：

sql复制ALTER TABLE user AUTO_INCREMENT = 1;

也可以把自增ID重置回1。

4.4 误删除后的恢复思路

说到DELETE，就不得不提误删除的恢复。虽然希望大家都用不上，但真遇到了，慌乱没用，按下面这个优先级去处理，能挽回多少是多少。

第一道防线是业务日志和代码。如果删除操作是由应用代码发起的，那么代码日志里通常会记录这次操作的SQL和参数，运气好的话可以直接还原出被删掉的数据。

第二道防线是数据库备份。如果开启了定时备份，找到最近一次备份，把备份恢复到临时库，再把需要的数据导回来。这里强调的是"临时库"，千万别直接在现网库上做恢复操作，容易越搞越乱。

第三道防线是二进制日志（binlog）。MySQL的binlog记录了所有数据变更，可以通过日志定位到误删除时间点之前的位置，使用mysqlbinlog工具把数据解析出来。这个操作有一定门槛，但关键时刻能救命。前提是你在配置里开启了binlog，很多本地练习环境默认没开，真等出事了才发现没有日志，那就只能自认倒霉了。

所以回到核心：日常备份比任何恢复技巧都重要。哪怕你只是个练习环境，养成定期备份的习惯，遇到问题才能从容处理。

5. 事务、锁与安全，增删改查背后的基本功

前面四节把增删改查本身讲透了，但如果只懂语法，不懂它们背后的机制，你写出来的操作在并发环境里会出各种意想不到的问题。最典型的就是"为什么我的UPDATE语句卡住了"、"为什么别人能查到数据，我却查不到"。这些问题的答案都在事务和锁里。搞清楚这两块，才能在真实项目中游刃有余。

5.1 事务：为什么增删改查要放在事务里

事务（Transaction）是一组SQL操作的集合，要么全部执行成功，要么全部不执行。最经典的比喻是转账：A账户扣100元，B账户加100元，这两条UPDATE要么都成功，要么都回滚。如果只执行了扣款而加款失败，钱就凭空消失了。

MySQL的InnoDB引擎默认自动提交，也就是每一条SQL单独就是一个事务：

sql复制-- 执行完立即生效，无法回滚
UPDATE user SET age = age + 1 WHERE id = 1;

要手动控制事务，用BEGIN或者START TRANSACTION开启：

sql复制BEGIN;

UPDATE user SET age = age - 1 WHERE id = 1;
UPDATE user SET age = age + 1 WHERE id = 2;

COMMIT;  -- 提交，真正生效
-- ROLLBACK;  -- 回滚，所有修改取消

事务的核心是ACID四个特性，逐个对应到实际操作：

• 原子性（Atomicity）：一组操作捆绑执行，要么全成要么全败。
• 一致性（Consistency）：事务执行前后，数据状态是合法的，没有被破坏。
• 隔离性（Isolation）：事务之间互不干扰，自己提交前的数据变更对别的事务不可见。
• 持久性（Durability）：事务一旦提交，数据变更就是永久的，即使数据库崩溃也不会丢。

我自己的使用习惯是：只要涉及两条或以上SQL的更新操作，一律放进事务里。比如用户下单，要写订单表、扣库存、更新用户积分，三个操作如果分三条SQL独立执行，中间任何一个失败都会留下脏数据。用事务包起来，要么全部成功，要么全部回滚。

5.2 行锁与表锁：为什么会出现锁表

锁是数据库用来处理并发修改的机制。热搜词里的"mysql锁表"，我见过的场景大概有这几种：

第一种，MyISAM引擎的全表锁。 MyISAM引擎的读写锁粒度是整张表，一旦有人写表，所有对这个表的读写操作都会排队等待。这就是为什么现在新项目几乎都选InnoDB——InnoDB支持行级锁，锁粒度更细，并发能力更强。

第二种，InnoDB的行锁等待。 InnoDB默认使用的是行级锁，但要注意，只有通过索引条件操作数据时才会使用行锁；如果更新条件没有走索引，InnoDB会锁住所有扫描到的记录，实际效果和表锁差不多。这提醒我们：UPDATE和DELETE的WHERE条件尽量都用索引字段，比如主键id或者有唯一索引的username。

第三种，事务未提交导致的锁等待。 这是最常见的一种"锁表"现象。两个连接同时操作同一行数据，A连接开启了事务，更新了某行但不提交，B连接再更新同一行时，就会一直卡住等待。你可能会疑惑：B为什么能查到数据却更新不了？因为未提交事务的变更对其他事务不可见，但这行数据上的锁是真实存在的，B的更新要等A提交或回滚才能继续。

遇到这种"卡住"的情况，第一件事就是查当前正在执行的事务和线程：

sql复制SHOW PROCESSLIST;

看哪些连接处于Sleep状态但长期占用连接，或者State列显示 "updating" 一直不变。找到对应的连接ID后，可以杀掉阻塞源：

sql复制KILL 12345;

大部分锁等待问题，本质上是事务没及时提交。这也解释了为什么我在上一节强调"事务操作完记得立刻COMMIT"，很多人开发完只记得BEGIN，忘了一整套流程里COMMIT挂在哪，事务长期开着不释放，连接池很快就满了。

5.3 日常安全红线与备份建议

最后，把我这几年操作MySQL的安全红线梳理一遍，每一条都是教训换来的：

第一条，生产环境禁止执行不带WHERE条件的UPDATE和DELETE。 这条没有任何商量的余地。就算要全表更新，也应该是先确认需求、走变更流程、做好备份之后再用事务分批处理，而不是直接一条SQL打上去。

第二条，不会的SQL先在测试库跑。 我见过不少人，在测试库验证了一条语句没问题，复制到生产库执行时，因为环境不同、数据不同，结果完全出乎意料。所以不仅要在测试库跑，还要在测试库里模拟生产的数据量级别再跑一遍，确认执行计划合理。

第三条，备份要常态化，并且要演练恢复。 备份不是"有就行"，你得知道备份文件怎么恢复、恢复需要多久。我见过团队有备份，但恢复出一个错误，等于没有备份。这里推荐最基础的备份方式，用mysqldump逻辑备份，简单可靠：

bash复制mysqldump -uroot -p demo > demo_backup.sql

恢复也简单：

bash复制mysql -uroot -p demo < demo_backup.sql

第四条，命令行操作时，不要同时开着多个窗口执行DDL或大范围DML。 你开着事务忘了提交，其他窗口的所有操作都会受影响。这种"自己锁死自己"的场景，排查起来往往最浪费时间。

增删改查学到最后，你会发现最难的不是记住语法，而是养成一种"对数据有敬畏感"的习惯。每次按下回车之前，多想一下这条语句会影响到哪些数据、影响范围是不是自己预期的、如果出错了有没有后悔药。这套习惯，才是从新手到熟手真正的分水岭。我自己刚接触MySQL那会儿，也在测试库里把一整张表的数据UPDATE错过，当时没开事务只能硬着头皮从备份恢复，折腾到半夜。从那之后，凡是要动线上数据，我脑子里永远先过三件事：SELECT确认范围、事务包裹、备份就位。希望你不用像我一样踩那么深的坑，但你一定要知道，工具的便利背后，责任从来都在自己手里。