要上进的柯同学增删改查这四件事，可能是大多数人和 MySQL 打交道的第一步。我刚入行那会儿也觉得，CRUD 嘛，背几条 SQL 语法就能上手，能有多难？可真到生产环境里跑过几年之后才发现，同样是写INSERT、SELECT、UPDATE、DELETE，有人写出来的东西在几十万数据量下照样秒回，有人写出来的东西在几千条数据时就能把数据库拖垮。差别不在语法，而在对数据操作底层逻辑的理解。这篇东西我就从实战角度，把 MySQL 增删改查里值得琢磨的细节、容易踩的坑、还有我个人的操作习惯一次性捋清楚，希望能帮你少走点弯路。
1. 增删改查的本质：别把 CRUD 只当成四句语法
很多人学 MySQL 增删改查，是从背语句开始的：INSERT INTO搞定写入，SELECT搞定查询，UPDATE搞定修改，DELETE搞定删除。语法本身确实不难，难的是理解这四类操作在数据库内部到底做了什么，以及它们之间怎么互相影响。
1.1 为什么说 CRUD 是所有业务系统的地基
你可以把任何一套业务系统想象成一个记账本：用户注册是增，用户登录是查，用户改头像昵称是改，用户注销是删。所有互联网产品的核心功能，归根到底都是这四类操作的组合。正因如此，CRUD 的性能、稳定性和安全性，几乎决定了整个业务系统的上限。
我跟很多刚入门的朋友交流时发现一个普遍现象：大家觉得增删改查太简单，不值得花心思研究。但实际上，生产环境里的 CRUD 和教科书上的 CRUD 完全不是一回事。教科书教你的是"怎么写能跑通"，生产环境要求的是"怎么写才能扛住并发、不走全表扫描、不锁住整张表、不出脏数据"。举个例子，同样是插入一万条数据，一条条循环INSERT可能要几秒钟，而用批量插入的方式可能只要几十毫秒。绝大多数初学者不会意识到这种差异，但在真实项目中，这种差异就是线上事故和正常运行的差别。
1.2 数据结构设计决定了 CRUD 的复杂度上限
还有一个更隐蔽的因素：增删改查好不好写、性能好不好，很大程度在表结构设计阶段就定下来了。
有一句话叫"三流程序员写代码，一流程序员设计表"。如果你的表设计不合理，比如该建索引的字段没建、字段类型选得过大、表之间关系混乱，那后面的所有SELECT查询都会变得拧巴，所有UPDATE和DELETE都会变得危险。反过来说，一张设计良好的表，能让增删改查的业务逻辑非常简洁。
以用户表为例，我见过不少新手拿VARCHAR(255)存用户ID、拿TEXT存手机号，这种类型选型会导致两个问题：一是存储空间浪费，索引体积变大，查询变慢；二是语义不清晰，索引长度太长，联合索引根本没法设计。正确做法是能用INT或BIGINT的绝不用字符串，能用CHAR的不要用VARCHAR，能用DATETIME的不要用字符串存时间。表结构设计是 CRUD 的地基，地基歪了，上面写多少优化技巧都白搭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. INSERT 插入数据：批量插入与并发写入的正确姿势
插入操作看起来最简单，就是把数据写进去，但恰恰是很多性能问题的源头。我在实际项目中处理过几次写入慢的问题，最后发现根子都出在插入方式上。
2.1 单条插入与批量插入的性能差距
先看一个最典型的场景：往一张表里插入一万条数据。新手最常见的写法是在代码里循环一万次，每次都执行一句：
sql复制INSERT INTO user (name, age, city) VALUES ('张三', 25, '北京');
这种方式每执行一次，MySQL 都要做一次 SQL 解析、权限检查、事务处理，还要同步一次日志，开销非常大。实测下来，在普通配置的机器上，循环插入一万条可能需要几秒甚至十几秒。
而换成批量插入：
sql复制INSERT INTO user (name, age, city) VALUES
('张三', 25, '北京'),
('李四', 30, '上海'),
('王五', 28, '广州');
一次把多条记录拼在同一个INSERT语句里，MySQL 只需要解析一次 SQL，日志写入也只需要同步一次。同样是插入一万条，耗时往往能缩短到原来的十分之一甚至更低。我在一个数据迁移项目里，就是把百万级数据的逐条插入改成每 500 条一批的批量插入，整体耗时从四十多分钟降到了三分钟以内，效果立竿见影。
提示：批量插入也不是越大越好。一次插入 500 到 1000 条是实践下来比较稳妥的范围。如果单条
VALUES数量太多，SQL 语句会变得很长，占用内存增加，还可能导致主从复制的延迟增大。要根据实际场景找到适合自己的批量大小。
2.2 INSERT 与事务的配合：要么全成功，要么全失败
如果你往多张表里插入数据，比如注册一个用户，既要写用户表，又要写用户的扩展信息表，那这两条插入操作必须放在同一个事务里。否则一旦写第二张表的时候报错，第一张表的数据就变成了"孤立数据"。
事务的正确写法是：
sql复制START TRANSACTION;
INSERT INTO user (id, name) VALUES (1, '张三');
INSERT INTO user_profile (user_id, age, city) VALUES (1, 25, '北京');
COMMIT;
如果第二步插入失败，就执行ROLLBACK回滚，保证数据库不会残留一半的数据。这个习惯必须养成，尤其在生产环境里，不用事务的裸插入操作，是要出大问题的。
2.3 INSERT ... ON DUPLICATE KEY UPDATE 的适用场景
还有一种高频需求：一条数据如果不存在就插入，如果存在就更新。比如用户每天的签到记录，或者按订单号去重的业务数据。很多人第一反应是先查一遍，再看有没有，有就更新，没有就插入。这样虽然逻辑上没错，但性能很差，而且还存在并发问题：两个请求同时查到不存在，然后同时插入，其中一个就会报主键冲突。
更优雅的方案是用 MySQL 提供的ON DUPLICATE KEY UPDATE语法：
sql复制INSERT INTO sign_record (user_id, sign_date, sign_count)
VALUES (1001, '2024-06-01', 1)
ON DUPLICATE KEY UPDATE sign_count = sign_count + 1;
这里的前提是user_id和sign_date有唯一索引。执行时，如果记录不存在就直接插入；如果存在就执行后面的更新语句。一条 SQL 解决"存在则更新、不存在则插入"的问题，既避免了并发冲突，又省掉了一次查询，是我在实际项目中非常喜欢用的写法。
2.4 插入操作中的常见坑
- 字段与值不匹配：插入时列的个数和值的个数不一致，或者类型不匹配，MySQL 会直接报错。这个看似低级，但在动态拼接 SQL 的场景下经常出现。
- 字符集问题导致乱码：如果你的表是
utf8mb4，但程序连接的字符集配的是latin1，插入的中文就会变成乱码。写连接串时务必加上characterEncoding=utf8之类的参数。 - 数据过长被截断：MySQL 在非严格模式下，数据长度超出字段定义时不会报错，而是静默截断，很容易造成数据丢失。建议把
sql_mode设置成严格模式，让超长数据直接报错而不是悄悄截断。
3. SELECT 查询：执行顺序和索引机制决定查询快慢
SELECT 是 CRUD 里使用频率最高、也最能体现技术水准的操作。同一个需求，不同人写出来的 SQL，执行效率可能差几十倍。要写出高性能的查询，必须先搞清楚 MySQL 到底按什么顺序执行一条 SELECT 语句。
3.1 一条 SELECT 语句的执行顺序
SQL 的书写顺序和执行顺序是不一样的。很多人以为 MySQL 是从FROM开始读表，然后按WHERE过滤，其实完整的逻辑执行顺序是这样的：
FROM：确定从哪张表取数据ON：如果是多表连接，先在连接条件上过滤JOIN：执行连接操作WHERE：对基础表过滤GROUP BY：分组HAVING：对分组后的数据过滤SELECT：确定要返回的列DISTINCT：去重ORDER BY：排序LIMIT：限制返回行数
理解这个顺序最大的价值在于：你要想清楚每一步操作的数据量是多少。比如WHERE是在分组之前执行的，所以能在WHERE里过滤掉的数据，绝对不要留到HAVING里再过滤，因为后者要去处理的数据量已经大得多了。
我举一个实际例子。查询每个城市中年龄大于 25 岁的用户数量：
sql复制SELECT city, COUNT(*)
FROM user
WHERE age > 25
GROUP BY city;
如果错误地写成先分组再去HAVING里过滤年龄：
sql复制SELECT city, COUNT(*)
FROM user
GROUP BY city
HAVING age > 25;
不仅逻辑上可能是错的（HAVING里出现非分组字段在严格模式下会直接报错），就算某些场景能跑，性能也远远不如把过滤条件放在WHERE里。这就是理解执行顺序的直接收益。
3.2 索引：让查询从"翻整本书"变成"查目录"
索引是 MySQL 性能优化的核心，没有之一。一张表没有索引时，查询要一行一行地扫描全表，数据量越大越慢。而有了索引之后，MySQL 可以直接通过 B+ 树的路径找到目标数据，速度提升几个数量级。
以用户表为例，如果经常按email查用户，就应该给email字段建索引：
sql复制CREATE INDEX idx_email ON user (email);
之后执行：
sql复制SELECT * FROM user WHERE email = 'zhangsan@example.com';
MySQL 会直接走idx_email索引，而不是全表扫描。我在一个实际项目中遇到过接口超时的问题，排查下来就是一条查询没走索引，在一个 200 万行的表上全表扫描，每次查询要 3 秒多。加上索引之后，同样的查询降到 30 毫秒以内，效果惊人。
3.3 索引失效的常见场景
不过索引也不是建了就一定生效，很多操作会让索引失效。我在面试别人或者帮别人排查问题的时候，总结出几个高频原因：
- 对索引列使用了函数，例如
WHERE YEAR(create_time) = 2024，这种情况下索引会失效。正确写法是WHERE create_time >= '2024-01-01' AND create_time < '2025-01-01'。 - 隐式类型转换，比如索引字段是字符串，却拿数字去比较。MySQL 会先对字段做类型转换，导致索引失效。
- 左模糊查询
LIKE '%abc'，因为 B+ 树索引是从左到右匹配的，前导通配符让索引无从下手。 - 联合索引没有遵循最左前缀原则，跳过了第一个字段直接查第二个字段。
这些坑都很隐蔽，尤其是隐式类型转换。我在一次排查中就发现，用户表的手机号字段明明建了索引，但查询一直很慢，原因就是 Java 代码传了一个Long类型的手机号过来，MySQL 自动把它转成字符串来比较，索引直接失效。改掉数据类型之后，问题立刻解决。
3.4 排序、去重与常用函数
排序ORDER BY和去重DISTINCT也是 SELECT 里非常常用的操作。关于排序，要记住一个原则：如果排序字段有索引，MySQL 可以直接利用索引顺序，不需要额外的排序操作；如果没有索引，MySQL 就要把数据先捞出来再排序，数据量一大就会慢。所以高频排序的字段，值得建索引。
关于去重，很多人不知道DISTINCT和GROUP BY在去重这件事上是可以互相替代的。简单场景下SELECT DISTINCT city FROM user和SELECT city FROM user GROUP BY city效果一样。但如果还要统计数量，就必须用GROUP BY配合COUNT(*)了。
MySQL 常用函数方面，我平时用得最多的是这几类：字符串函数（CONCAT、SUBSTRING、LENGTH）、日期函数（NOW、DATE_FORMAT、DATEDIFF）、聚合函数（COUNT、SUM、AVG、MAX、MIN）、条件函数（IF、CASE WHEN）。这些函数掌握之后，很多原本要在程序里做的处理，可以直接下推到 SQL 里完成，减少应用层和数据库之间的数据传输。
4. UPDATE 修改数据：影响行数、事务回滚与锁的博弈
UPDATE和DELETE一样，都属于高危操作。原因很简单：它们的杀伤力是"范围性"的，一旦条件写错，受影响的不是一条数据，而是所有满足条件的行。
4.1 没写 WHERE 的 UPDATE：新手最容易犯的致命错误
先看一个经典事故场景。运营同事想要把某个用户的余额加上 100 元，SQL 是这样写的：
sql复制UPDATE user SET balance = balance + 100;
少了一个WHERE id = xxx。结果是什么？全表所有用户的余额都被加了 100 元。如果线上没有备份，且数据不能回退，这就是一场技术事故。
MySQL 客户端默认开启了自动提交（autocommit = 1），每一条UPDATE执行完就立即提交了，根本不给后悔的机会。所以我在实际操作中，养成了一条铁律：
执行 UPDATE 或 DELETE 之前，先把 WHERE 条件单独拿出来跑一遍 SELECT，确认影响的数据范围和预期一致，再执行真正的修改。
比如要修改某个用户的余额，我会先执行：
sql复制SELECT id, balance FROM user WHERE id = 10086;
确认查出来的就是目标用户，然后再执行更新。这个习惯看起来多了一步，但能挡掉绝大多数低级事故。
4.2 事务与行锁：更新操作背后的并发控制
当多个请求同时更新同一行数据时，就会涉及锁。MySQL 的 InnoDB 引擎默认使用行级锁，也就是说，一个事务更新某一行时，会把这行锁住，直到事务提交或回滚，期间其他事务不能修改这一行。
举个例子，一个经典的并发扣库存问题。商品表里库存只剩 1 件，两个用户同时下单要扣库存。如果代码逻辑是"先查库存，够就扣减"，在高并发下就可能出现两个事务同时查到库存为 1，然后都执行扣减，最后库存变成 -1 的情况。正确做法是直接在一条 UPDATE 里完成条件更新：
sql复制UPDATE product
SET stock = stock - 1
WHERE id = 123 AND stock > 0;
执行完后，如果影响行数为 1，说明扣减成功；如果影响行数为 0，说明库存不足。这个方案用一条 SQL 和行锁天然解决了超卖问题，比"先查再改"的方式可靠得多。注意检查 UPDATE 的影响行数，是一个很容易被忽略但其实非常关键的技巧。
4.3 大批量更新怎么做才安全
生产环境里有时需要一次性更新大量数据，比如给所有注册满一年的用户发 100 积分。如果用一条 UPDATE 更新几十万行，会带来几个问题：一是会长时间锁住大量行，影响其他业务的读写；二是一旦中途报错，整个大事务回滚的代价非常高；三是会拉大主从复制的延迟。
更稳妥的做法是分批更新，比如每次只更新 1000 行：
sql复制UPDATE user
SET points = points + 100
WHERE register_time < '2023-06-01'
LIMIT 1000;
然后循环执行这条 SQL，直到影响行数为 0。这样每一批事务都很短，锁的范围小，即使中途出问题，也能从断点继续，不会造成长时间锁表。
5. DELETE 删除数据：真正的高危操作与替代方案
删除是四类操作里最需要敬畏的一个。数据一旦被删除，如果没有备份，几乎不可能找回。而且删除操作对性能的影响也很大，绝不是简单执行一条 SQL 就完事。
5.1 删除前的三问：删哪条、影响多少、能不能恢复
我给自己定了一个规矩，执行 DELETE 之前必须先回答三个问题：
- 要删除的具体是哪些行？WHERE 条件能不能精确定位？
- 这条删除会影响多少行？有没有可能误伤？
- 删除了能不能恢复？有没有备份？
第三个问题最关键。我的建议是，在删除数据之前，先把要删的数据备份到另外一张临时表，比如：
sql复制CREATE TABLE user_deleted_20240601 AS
SELECT * FROM user WHERE create_time < '2020-01-01';
确认备份没问题之后，再执行：
sql复制DELETE FROM user WHERE create_time < '2020-01-01';
这样即使删错了，也能从备份表里把数据捞回来。我在实际项目里做过很多次类似的清理操作，每次都先备份，这个习惯让我避免了好几次潜在的事故。
5.2 大批量删除：直接删一张大表的数据有多危险
很多人以为 DELETE 只是把数据删掉就完了，实际上 InnoDB 在删除大量数据时，并不会立刻释放磁盘空间，而是先给删除的行打上标记，后续由后台线程逐步清理。这个过程中，表文件会暂时产生大量碎片，磁盘空间不一定马上降下来。
更重要的是锁问题。一条不带 WHERE 的 DELETE 会锁住所有行，如果是几百万行的大表，可能导致线上业务长时间不可用。即使是带 WHERE 条件的大批量删除，锁的范围也可能很大。
正确做法同样是分批删：
sql复制DELETE FROM user
WHERE create_time < '2020-01-01'
LIMIT 1000;
循环执行，每次删一小批，直到影响行数为 0。我实测过，这种分批删除在大表上比一次性删除性能更可控，对线上业务的冲击也小得多。
5.3 DELETE、TRUNCATE、DROP 到底怎么选
很多新手分不清这三个操作的区别，我在这里说一下：
DELETE：删除表中的部分或全部数据，可以通过 WHERE 限定范围，支持事务回滚，是 DML 操作，会逐行删除并记录日志。删除大量数据时性能较慢。TRUNCATE：清空整张表，不逐行记录日志，速度快得多，但不能回滚**（在 MySQL 中默认行为）**，会重置自增计数。物理上直接重建表结构。DROP：直接删除整张表，包括表结构和数据，彻底不可恢复。
什么场景用哪个？我的建议是：
- 要删部分数据，用 DELETE，务必带上 WHERE 和 LIMIT。
- 要清空某张表的全部数据，但保留表结构，用 TRUNCATE，速度最快。
- 整张表都不要了，直接用 DROP。
从安全角度排序，DROP > TRUNCATE > DELETE，越往左越需要谨慎。
6. 从增删改查延伸出去：锁、备份、工具与面试高频点
当你能熟练完成基本的增删改查之后，后面的进阶路线就清晰了。这里我聊聊从 CRUD 延伸出去的几个方向，这些也是我实际工作中反复接触的东西。
6.1 锁表问题的定位与处理思路
增删改查做得多了，一定会遇到"锁"相关的问题。最常见的表现是：一条 UPDATE 或者 DELETE 执行到一半卡住了，后续对同一张表的操作全部阻塞，show processlist 里能看到一堆线程处于"Waiting for table metadata lock"或者"Waiting for lock"状态。
遇到锁问题，我的一般排查流程是：
- 执行
SHOW PROCESSLIST;或直接查information_schema.innodb_trx表，找到正在执行且长时间未提交的事务。 - 找到"罪魁祸首"之后，评估是等它执行完，还是手动终止这个线程。
- 如果是误操作引起的长事务，用
KILL命令终止对应线程。
更重要的还是预防：所有的增删改查操作都尽量保持事务短小，不要在事务里做耗时的外部调用，不要大范围更新不加 LIMIT，这些都能有效减少锁冲突。
6.2 常用工具与客户端：命令行、Workbench 与可视化工具
动手练增删改查，工具也很关键。最基础的是 MySQL 自带的命令行客户端，连接方式：
bash复制mysql -u root -p -h 127.0.0.1 -P 3306
命令行适合快速执行 SQL 和写脚本，但日常开发调试，我更喜欢用 MySQL Workbench，它是 MySQL 官方推出的图形化客户端，可以直接查看表结构、执行 SQL、看执行计划、导出 ER 关系图，非常适合刚开始学习的人。
在排查慢查询时，Workbench 里有一个很实用的功能，就是在查询语句前加上EXPLAIN：
sql复制EXPLAIN SELECT * FROM user WHERE email = 'zhangsan@example.com';
它会展示这条查询有没有走索引、扫描了多少行、用到了哪个索引。学会看执行计划，是增删改查水平提升的分水岭，很多性能问题在这一步就能定位出来。
6.3 增删改查相关的面试高频题
我在面试中经常问候选人一些增删改查背后的问题，这里也整理几个高频的，供大家自查：
CHAR和VARCHAR的区别？VARCHAR(50)里的 50 是字符还是字节？（答：字符）COUNT(*)、COUNT(1)、COUNT(column)有什么区别？（答：COUNT(*)统计所有行，COUNT(1)本质上和COUNT(*)一样，COUNT(column)只统计该列非 NULL 的行）- 一条 UPDATE 语句执行后影响行数怎么获取？有什么用？（答：可以用它判断是否有匹配记录，比如乐观锁更新）
- 为什么 DELETE 删除数据后表空间没有变小？（答：InnoDB 是标记删除，需要后续清理）
- 什么是索引失效？你遇到过哪些场景？
- 存储过程、触发器在什么场景下会用到？（我一般建议能不用就不用，逻辑放到业务层更可控，但在某些批量数据处理的场景，存储过程确实能减少网络往返）
这些问题虽然都会以增删改查为出发点，但背后考察的都是对数据库机制的理解深度。我建议初学者不要停留在"能跑通"的层面，多问自己一句"为什么"，收获会大很多。
6.4 备份与恢复：增删改查最后的兜底防线
无论你的 SQL 写得有多熟练，都必须承认一个事实：人一定会犯错。所以备份不是可选项，而是必选项。MySQL 最常用的备份工具是mysqldump，比如备份整个数据库：
bash复制mysqldump -u root -p mydb > mydb_backup.sql
恢复也很简单：
bash复制mysql -u root -p mydb < mydb_backup.sql
我个人的习惯是：数据库变更操作之前都先备份一次，变更之后观察一段时间再清理备份。这个习惯虽然看起来麻烦，但在关键时刻能救命。尤其是做 DELETE、大批量 UPDATE、结构修改这类操作，备份就是你的安全气囊。
从我自己的经验来看，增删改查表面上翻来覆去就十几个关键字，但真正把它理解透了，牵扯出来的是索引原理、事务隔离级别、锁机制、执行计划、备份恢复一整套知识体系。这篇文章写的都是我日常工作中反复用到的内容。如果你是刚开始接触 MySQL，建议把每种操作都实际跑一遍，然后刻意练习一下"不用 SELECT 查一遍就不做 UPDATE/DELETE"这个习惯。等到你哪一天写出一条复杂的多表关联查询，能条件反射式地说出它的执行顺序和可能用到的索引时，你就已经比大多数人强了。