MySQL增删改查实战：从CRUD到事务锁与性能优化

做了这么多年后端开发，我有个特别深的体会：不管业务多复杂，最后落到数据库上，无非就是四件事——增、删、改、查。这也就是大家常说的CRUD（Create、Read、Update、Delete）。MySQL作为最常用的关系型数据库之一，把这四个操作吃透，基本就掌握了日常开发中80%的数据处理需求。但这四个操作看着简单，真要把每一条SQL都写对、写稳、写出性能，里面还是有不少门道的。

这篇内容我会从最基础的环境准备开始讲，一步步带你建库、建表，然后逐条拆解INSERT、SELECT、UPDATE、DELETE这四类语句的完整用法。中间会穿插我平时干活时踩过的坑、积累的排查经验，包括表字段设计、字符集选择、事务锁表、误删恢复这些偏实战的内容。无论你是刚入门的学生、准备面试的求职者，还是写了好几年业务代码但没系统梳理过SQL细节的开发，这篇文章都应该能帮到你。

1. 动手前的准备：建库建表才是第一道坎

很多人一上来就急着写增删改查，结果连表结构都没设计明白，后面全是坑。我见过太多因为字段类型选错、字符集没配好导致的数据错乱案例。这一节先把基础设施搞定。

1.1 建库与字段类型选择的底层逻辑

先看一个最基础的建库语句：

sql复制CREATE DATABASE IF NOT EXISTS school 
DEFAULT CHARACTER SET utf8mb4 
COLLATE utf8mb4_unicode_ci;

这里有两个重点值得多说几句。第一是 IF NOT EXISTS，加上它之后，即使数据库已经存在也不会报错，这在写初始化脚本的时候非常实用。第二是字符集，我强烈建议统一用 utf8mb4，不是老的 utf8。原因很简单，MySQL的 utf8 最多只支持3字节，像 emoji 表情和一些生僻字根本存不进去，而 utf8mb4 是完整的4字节编码，兼容性最好。排序规则选 utf8mb4_unicode_ci 就行，它基于Unicode标准排序，日常开发和数据比对基本不会出问题。

建完库之后就是建表。这里我用一张学生信息表来演示，这也是增删改查最典型的应用场景：

sql复制CREATE TABLE students (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    student_no VARCHAR(20) NOT NULL COMMENT '学号',
    name VARCHAR(50) NOT NULL COMMENT '姓名',
    age TINYINT UNSIGNED DEFAULT 0 COMMENT '年龄',
    score DECIMAL(5,2) DEFAULT 0.00 COMMENT '成绩',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (id),
    UNIQUE KEY uk_student_no (student_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

这张表里的字段类型就是我平时做设计的参考模板。id 用 INT UNSIGNED 配合自增主键，省心又高效；学号这种需要唯一性的业务字段，用 VARCHAR(20) 加唯一索引；年龄用 TINYINT UNSIGNED，因为它的取值范围是 0 到 255，存年龄完全够用，比 INT 节省3个字节；成绩用 DECIMAL(5,2)，表示最多5位数字、其中2位是小数，最大999.99，存学生成绩足够了。

注意：千万别用 FLOAT 或 DOUBLE 存金额、成绩这类需要精确计算的数值，浮点数会有精度丢失。我见过用 FLOAT 存金额导致对不上账的线上事故，教训非常深刻。固定精度的小数，一律上 DECIMAL。

关于 created_at 和 updated_at 这两个字段，我的习惯是每个表都加上。DEFAULT CURRENT_TIMESTAMP 会在插入时自动写入当前时间，ON UPDATE CURRENT_TIMESTAMP 会在数据更新时自动刷新，这样你做数据审计、排查问题的时候非常方便，不用自己手动维护时间。

1.2 修改表结构：ALTER TABLE 的正确姿势

建表之后加字段、改字段也是常事，ALTER TABLE 的语法要熟练。加字段、删字段、改字段类型的标准写法如下：

sql复制-- 添加字段
ALTER TABLE students ADD COLUMN address VARCHAR(255) DEFAULT '' COMMENT '家庭住址';

-- 修改字段类型
ALTER TABLE students MODIFY COLUMN name VARCHAR(100) NOT NULL COMMENT '姓名';

-- 删除字段
ALTER TABLE students DROP COLUMN address;

-- 修改字段名
ALTER TABLE students CHANGE COLUMN score total_score DECIMAL(5,2) DEFAULT 0.00 COMMENT '总成绩';

这里要区分 MODIFY 和 CHANGE：MODIFY 只能改类型、默认值、注释等属性，改不了字段名；CHANGE 可以连字段名一起改，但必须把新字段名和完整定义都写出来。还有一个容易被忽略的点：在数据量大的表上执行 ALTER TABLE，MySQL 8.0 之前很多操作会锁表，导致业务短暂中断。如果是在生产环境操作，尽量选择业务低峰期，或者用专门工具分批次执行，避免长时间锁表影响线上服务。

2. 增：INSERT 语句的完整实战拆解

建好表之后，第一个要面对的操作就是插入数据。插入看似简单，但批量插入、冲突处理、注意事项，每一块都有讲究。

2.1 单条插入、批量插入与主键冲突处理

最基础的插入语句长这样：

sql复制INSERT INTO students (student_no, name, age, score) 
VALUES ('2024001', '张三', 20, 88.5);

注意我列了字段名，这是一个非常推荐的习惯。如果省略字段名直接写 INSERT INTO students VALUES (...)，就必须按表定义顺序把所有列的值都填上，一旦表结构调整过，SQL就直接跑错了。而显式列出字段名，代码可读性更好，后续加字段也不容易踩坑。

批量插入的正确姿势：

sql复制INSERT INTO students (student_no, name, age, score) VALUES 
('2024002', '李四', 21, 92.0),
('2024003', '王五', 19, 75.5),
('2024004', '赵六', 22, 68.0);

批量插入除了语法上更简洁，性能也好很多。MySQL执行多条独立INSERT和一条多VALUES语句，底层I/O次数差别很大，后者能减少日志写入和网络往返。我测过，插入1000条数据，批量方式比循环单条插入快一个量级。

再来说说主键冲突。业务场景里经常会遇到"有就更新，没有就插入"的需求，比如同步数据、记录用户学习进度这种。手动判断会多一次查询，更好的方式是使用 ON DUPLICATE KEY UPDATE：

sql复制INSERT INTO students (student_no, name, age, score) VALUES ('2024001', '张三', 20, 90.0)
ON DUPLICATE KEY UPDATE 
name = VALUES(name),
age = VALUES(age),
score = VALUES(score);

这条语句的语义是：如果 student_no 唯一键冲突了，就执行后面的 UPDATE 把字段更新掉。在MySQL 8.0.20及以上版本中，VALUES() 函数在 ON DUPLICATE KEY UPDATE 里被标记为废弃，官方推荐使用别名语法，写成 AS new ON DUPLICATE KEY UPDATE name = new.name。虽然旧写法还能跑，但建议新项目直接用新语法，避免将来升级踩坑。

2.2 插入时最常踩的坑

插入数据这件事，看起来简单，实际用久了才知道坑不少。我总结几个高频问题：

• 字符集不一致导致的报错。如果表是utf8mb4，但连接字符集是latin1，插入中文就可能报 Incorrect string value。解决办法是连接串上加 characterEncoding=utf8（Java）或者建库建表时统一字符集。
• 非空约束。插入时没给 NOT NULL 字段传值，会直接报 Field 'xxx' doesn't have a default value。排查思路是回看表结构，确认哪些字段不能为空。
• 自增主键不连续。DELETE掉几条数据后再插入，自增ID不会复用，这是正常现象，不用纠结。
• 严格模式。MySQL 5.7之后默认开启严格模式，插入超过字段长度的数据会报错，而不是像以前那样自动截断。这是好事，能拦住很多脏数据。

还有一点很多人不知道：如果你在代码里用ORM框架（比如MyBatis），批量插入的 foreach 标签拼接SQL时要注意SQL长度限制。超过 max_allowed_packet 的值会报错，建议每批500到1000条分批执行，这个数量级经实测比较稳。

3. 查：SELECT 语句是重中之重

增删改查里，查的使用频率最高，语法也最灵活。你能不能把数据查得又快又准，直接决定了业务功能的成败。这一节我按使用频率从高到低拆解。

3.1 条件过滤与运算符的搭配使用

SELECT 最基本的结构是 SELECT 字段 FROM 表 WHERE 条件，但实际场景远比这个复杂。WHERE 子句里可以用各种运算符组合条件：

sql复制-- 基础条件
SELECT id, name, age FROM students WHERE age >= 20;

-- 多条件组合
SELECT * FROM students WHERE age > 18 AND score >= 80;
SELECT * FROM students WHERE age < 18 OR score >= 90;

-- IN 与 BETWEEN
SELECT * FROM students WHERE age IN (18, 19, 20);
SELECT * FROM students WHERE score BETWEEN 60 AND 90;

-- 空值判断，注意不能用 = NULL
SELECT * FROM students WHERE address IS NULL;
SELECT * FROM students WHERE address IS NOT NULL;

这里有一个很多人会犯的低级错误：判断NULL时用了 = NULL，结果一条数据都查不出来。因为NULL在SQL里代表"未知"，任何与NULL的直接比较都返回"未知"，不是真也不是假，必须用 IS NULL 或 IS NOT NULL。这个坑在面试和实际开发里都高频出现。

OR 和 IN 的转换也是一个优化细节。举个例子，WHERE age = 18 OR age = 19 OR age = 20 完全可以用 WHERE age IN (18,19,20) 替代。IN 写法不仅简洁，解析成本也更低，某些优化器还会把 IN 列表改写成索引范围内的多个等值判断，执行效率更高。

3.2 LIKE模糊查询与NULL的克星

模糊查询最典型的用法是搜索，比如按姓名找学生：

sql复制-- 以"张"开头
SELECT * FROM students WHERE name LIKE '张%';

-- 包含"三"
SELECT * FROM students WHERE name LIKE '%三%';

-- 以"三"结尾
SELECT * FROM students WHERE name LIKE '%三';

通配符 % 代表任意长度的字符，_ 代表单个字符。如果业务要求字符串里同时包含 % 或 _ 本身，需要用反斜杠转义，写成 LIKE '%\%%'。这里要特别注意：LIKE '%关键词%' 这种写法，因为前导通配符的存在，即使字段上有索引也无法使用，会引发全表扫描。如果数据量大，建议改用全文索引或者专业的搜索方案，实在要用 LIKE，也要尽量避免前置 %。

3.3 排序、分页与去重的核心细节

排序在业务里很常用，比如按成绩从高到低展示学生列表：

sql复制SELECT * FROM students ORDER BY score DESC, id ASC;

DESC 表示降序，ASC 表示升序。多个排序字段用逗号分隔，先按第一个字段排，如果值相同再按第二个字段排。这里我的建议是：排序字段后面显式写 ASC 或 DESC，不要省略，这样团队协作时别人一眼就能看懂你的排序意图。另外如果排序字段是字符串类型，排序规则受字符集影响，中文排序在不同 collation 下结果会不一样，需要特别注意。

分页是最常见的查询需求，MySQL的语法是 LIMIT offset, row_count：

sql复制-- 每页20条，查询第3页
SELECT * FROM students ORDER BY id LIMIT 40, 20;

offset 的计算公式是 (页码 - 1) * 每页条数。这里有个性能问题：offset 越大，MySQL需要扫描并跳过越多的行，效率越低。比如 LIMIT 1000000, 20 会先扫描100万行再丢弃，非常浪费。优化方案是用"延迟关联"或者基于上一页最后一条记录的ID来查询：

sql复制-- 利用主键索引直接定位
SELECT * FROM students WHERE id > 1000000 ORDER BY id LIMIT 20;

这种方式命中了主键索引的范围扫描，比大 offset 快很多。不过它要求业务场景是"下一页"式的浏览，不能用来自定义跳页。

去重也是一个高频操作。SELECT DISTINCT age FROM students 可以去除重复的年龄值。但要注意，DISTINCT 对多个字段生效是取多字段的组合去重，不是对每个字段分别去重。另外，如果只是想去掉某列重复值并且还要其他字段的数据，不能用 DISTINCT 硬扛，应该用 GROUP BY 或者窗口函数来实现。

我遇到过直接这么写的思路： SELECT name FROM students WHERE age=20 OR age=19，这就是OR的常规用法，没毛病。有些面试题会问"MySQL的OR能去重吗"，答案是不能，去重要么用 DISTINCT，要么用 UNION 而不是 UNION ALL，因为 UNION 本身会去重，代价是额外的排序和去重开销。能明确不需要去重时，用 UNION ALL 性能更好。

3.4 聚合查询与常用函数：从明细到统计

真实业务里不可能只看明细数据，统计报表更常见。聚合函数就是用来做统计的，常见的包括 COUNT、SUM、AVG、MAX、MIN：

sql复制-- 统计总人数
SELECT COUNT(*) FROM students;

-- 统计平均分、最高分、最低分
SELECT AVG(score), MAX(score), MIN(score) FROM students;

-- 按班级分组统计
SELECT class_id, COUNT(*) AS cnt, AVG(score) AS avg_score 
FROM students 
GROUP BY class_id;

COUNT(*) 是统计所有行数，而 COUNT(字段名) 只统计该字段不为NULL的行数，这两者在字段有NULL值时结果不同。比如 COUNT(address) 和 COUNT(*) 的结果就可能不一致，这个细节面试经常考。

GROUP BY 后面还可以接 HAVING 做分组后的过滤。注意 WHERE 是在分组前过滤，HAVING 是在分组后过滤，二者执行顺序完全不同：

sql复制-- 查出平均分大于80的班级
SELECT class_id, AVG(score) AS avg_score 
FROM students 
GROUP BY class_id 
HAVING avg_score > 80;

MySQL常用函数里，我日常用得最多的是这几类：日期函数 NOW()、DATE_FORMAT()；字符串函数 CONCAT()、SUBSTRING()、REPLACE()；条件判断 IF()、CASE WHEN。比如把成绩划分等级：

sql复制SELECT 
    name,
    score,
    CASE 
        WHEN score >= 90 THEN '优秀'
        WHEN score >= 80 THEN '良好'
        WHEN score >= 60 THEN '及格'
        ELSE '不及格'
    END AS level
FROM students;

CASE WHEN 在SQL里做逻辑分支非常灵活，比在Java代码里循环判断要优雅得多。

4. 改：UPDATE 语句的正确打开方式

改数据是风险最高的操作之一。一条UPDATE没写WHERE，可能就把整张表的数据都改了，这个错误几乎每个开发都犯过。这一节我会重点讲UPDATE的规范写法、数值操作和常见的联合更新。

4.1 基本语法与WHERE条件的"生死线"

UPDATE 的标准语法：

sql复制UPDATE students SET age = 21 WHERE name = '张三';

这里最核心的就是 WHERE。没有WHERE，就是全表更新，一旦执行没有后悔药。所以我的习惯是：写UPDATE之前，先把SELECT写出来查一遍，确认影响范围，再改成UPDATE执行。比如先执行 SELECT * FROM students WHERE name='张三'，看一眼返回结果没问题，再执行UPDATE。这个习惯救了我很多次。

UPDATE 后面可以同时更新多个字段，用逗号分隔：

sql复制UPDATE students 
SET age = 22, score = 91.5 
WHERE student_no = '2024001';

这里有一个高频考点，就是热搜词里那个"mysql中int+5"。很多新手不知道在SQL里怎么让数值字段加5，以为是 SET age = 5，那样会把age覆盖成5。正确的写法是：

sql复制UPDATE students SET age = age + 5 WHERE id = 1;

age = age + 5 的意思是：取出当前age值，加5之后再写回去。这种写法在库存扣减、积分累加、计数器递增等场景非常常见。但是要注意，这类操作在高并发场景下存在并发覆盖的问题，两个事务同时读到的age都是20，分别加5，最终结果变成25而不是30。解决方案是使用"原子操作"，也就是上面这条SQL本身（在单条语句内部是原子的），或者配合事务和行锁使用，后面事务章节我会细讲。

4.2 批量更新与多表关联更新

批量更新有两种常见场景。第一种是根据条件统一更新，比如考试成绩整体加5分：

sql复制UPDATE students SET score = score + 5 WHERE class_id = 1;

第二种是不同记录更新不同的值，需要一条条执行，也可以配合 CASE WHEN 一次性完成：

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

这种做法能在一次请求里完成多条差异化更新，减少了SQL往返次数。但如果数据量大、每次更新的逻辑又复杂，还是建议拆分事务批次处理，避免一次锁太多行。

多表关联更新也经常遇到，比如根据班级表里的信息同步更新学生表。语法是：

sql复制UPDATE students s
JOIN classes c ON s.class_id = c.id
SET s.class_name = c.name
WHERE c.grade = 2024;

这种JOIN UPDATE可以避免先查出来再在代码里循环更新的笨办法。不过要注意：多表更新前务必确认JOIN关系是唯一的，如果students表里有多个学生对应同一个class，而JOIN条件又不够精确，可能会更新到意外数据。我还是那句老话，执行前先改写成 SELECT 确认影响行数。

5. 删：DELETE 语句及安全删除策略

删数据比改数据风险还高，一个不留神就可能把核心业务数据清空。我见过不止一次因为DELETE不带WHERE导致线上事故的案例。这一节我不想只讲语法，更想分享一些"活下来"的经验。

5.1 DELETE基本用法与TRUNCATE的区别

删除单行或多行数据：

sql复制-- 删除指定记录
DELETE FROM students WHERE id = 10;

-- 删除符合条件的一批记录
DELETE FROM students WHERE class_id = 1 AND score < 60;

没有WHERE的DELETE会清空整表，这一点和UPDATE一样，务必极其谨慎。而且DELETE是逐行删除，会记录每一行到binlog，还会触发相关触发器，删除大量数据时性能比较差。

TRUNCATE 和 DELETE 的区别也值得讲清楚：

所以，如果只是清空一张临时表并且希望重置自增ID，用 TRUNCATE；如果需要删除一部分数据或者需要事务回滚保护，用 DELETE。另外还有一个高频操作是"删除全部数据但保留表结构"，不要用 DROP TABLE，那会把表结构和数据一起干掉，正确做法是 TRUNCATE 或者 DELETE。

5.2 误删数据后的应急方案

误删数据这事，谁碰上谁知道难受。下面这套应急流程是我自己整理的，建议收藏：

• 第一，立刻终止所有写操作。如果误删发生在主库，有条件的话马上把写入流量切换到从库或者直接暂停业务，防止新数据覆盖掉binlog里的恢复依据。
• 第二，确认binlog开启情况。MySQL的 log_bin 参数如果开启，并且binlog格式是 ROW，那你还有救。执行 SHOW VARIABLES LIKE 'log_bin'; 确认状态。
• 第三，利用binlog恢复。先通过 SHOW BINLOG EVENTS 找到误删语句的位置，然后使用 mysqlbinlog 工具把该语句之前的binlog导出，回放到数据库。在MySQL 8.0中，binlog的解析工具更友好，恢复思路一样。
• 第四，如果binlog没有开启，只能看有没有最近的物理备份或快照。所以在这里我强烈建议：核心库必须开启binlog，并且定期全量备份加实时增量备份。

另外还有一个更稳妥的做法：给删除操作加"软删除"标记。业务表加一个 is_deleted 字段，默认0；删除时不执行DELETE，而是 UPDATE ... SET is_deleted = 1。查询时统一过滤 is_deleted = 0。这个方案虽然增加了少量存储开销，但换来了"数据可回溯"的救命能力，特别适合用户数据、订单、账务等敏感场景。我负责过的所有核心业务表，无一例外都上了软删除。

6. 事务与锁：让增删改查更可靠

单看增删改查的每一条语句，好像都不难。但真实业务里，一个操作往往是多条SQL组合在一起，比如下单要同时扣库存、减余额、写订单。这些操作要么全部成功，要么全部失败，不能出现扣了库存却订单没创建的情况。这就是事务要解决的问题。

6.1 事务的ACID与手动控制

事务有四大特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），合起来就是ACID。原子性保证一组操作要么全做要么全不做；一致性保证数据从一种合法状态变为另一种合法状态；隔离性保证多个事务并发执行时互不干扰；持久性保证提交后数据不会丢失。

MySQL的InnoDB引擎默认开启自动提交，可以用 START TRANSACTION 手动开启事务：

sql复制START TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;

COMMIT;

如果中间任何一条SQL执行失败，可以执行 ROLLBACK 回滚，让之前的修改全部失效：

sql复制START TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
-- 这里发现异常
ROLLBACK;

需要特别注意的是：事务里执行的DDL语句（CREATE、ALTER、DROP）是不能回滚的，因为MySQL在执行DDL时隐式提交了当前事务。如果你在事务里先 ALTER TABLE 再发现逻辑错了，ALTER 那部分操作没法通过 ROLLBACK 撤销。所以，事务主要用于DML（增删改查），DDL操作要单独规划和评估。

6.2 锁表、行锁与并发冲突排查

事务的隔离性依赖锁机制实现。MySQL InnoDB 支持行级锁和表级锁，默认使用行锁，这也是为什么InnoDB比MyISAM更适合同等并发场景。但行锁用不好会变成"锁表"，影响整个系统的并发能力。

举一个典型场景：两个事务同时对同一行数据做更新，第二个事务会一直等待第一个事务提交或回滚，直到获取到锁。如果第一个事务迟迟不提交，就会出现会话卡死现象，看起来像"表被锁住了"。查看当前锁等待情况可以使用：

sql复制SHOW PROCESSLIST;

这个命令能列出当前所有连接会话的状态，State 列如果显示 Waiting for table metadata lock 或类似锁等待信息，就能大概率确定是锁冲突问题。进一步还能用 SHOW ENGINE INNODB STATUS 查看InnoDB的详细状态，里面包含最近死锁的检测信息。在实际开发中，遇到锁等待，第一时间检查是否有事务没提交就长期挂起，这种现象通常是代码里事务边界设置过长，或者事务内执行了耗时操作（比如调外部接口）导致的。

避免锁问题的关键几条经验：事务尽量短小，把耗时的计算放到事务外面；更新操作尽量命中索引，避免行锁升级为表锁；同一事务内更新多条记录时，保持固定顺序，减少死锁概率；避免在事务里跑大查询或者长时间持有连接。

7. 存储过程与触发器的增删改查扩展

前面讲的都是单条SQL的增删改查，但MySQL还支持把一组SQL打包成存储过程，以及在特定事件发生时自动执行触发器。虽然现在业务代码大多在应用层实现逻辑，但在一些报表系统、批处理任务里，存储过程仍然很有用。

一个简单的存储过程示例：

sql复制DELIMITER $$

CREATE PROCEDURE get_student_by_no(IN stu_no VARCHAR(20))
BEGIN
    SELECT * FROM students WHERE student_no = stu_no;
END$$

DELIMITER ;

存储过程的入参用 IN 声明，出参用 OUT。这里有个细节：MySQL默认用分号作为语句结束符，而存储过程内部又有很多分号，如果不先 DELIMITER $$ 把结束符临时改成 $$，MySQL会在第一个分号处就认为语句结束了，整个存储过程定义会报错。这就是热搜词里"mysql中触发器中分隔符"讨论的源头，指向的正是 DELIMITER 这个命令。

触发器则是当某个表执行INSERT、UPDATE、DELETE时自动触发的SQL逻辑。比如记录删除日志：

sql复制DELIMITER $$

CREATE TRIGGER trg_students_delete
AFTER DELETE ON students
FOR EACH ROW
BEGIN
    INSERT INTO students_log (student_no, name, deleted_at) 
    VALUES (OLD.student_no, OLD.name, NOW());
END$$

DELIMITER ;

触发器里能通过 OLD.字段名 访问被删除/更新前的值，通过 NEW.字段名 访问插入/更新后的值。不过我要提醒一句：触发器虽然方便，但它是隐式执行的，出了问题排查困难，而且会拖慢基础DML的性能。生产环境能用应用代码解决的就不要用触发器，我只有在做简单审计日志时才考虑它。

8. 常见问题与排查技巧实录

增删改查写多了，总会遇到各种莫名其妙的报错。我整理一个高频问题速查表，每一类都是我实际处理过的：

除了表格里的问题，我再分享几个排查思路。第一，SQL报错了不要只盯着报错信息看，先确定是语法问题还是数据问题，语法问题一般在错误信息里直接给出提示位置，数据问题往往和具体某条记录有关。第二，遇到"明明有数据却查不出来"的情况，优先检查字符集和排序规则，中文环境下这个坑尤其高发。第三，性能慢的查询，先用 EXPLAIN SELECT ... 查看执行计划，看有没有走索引，再考虑改写SQL或者加索引。

关于安装和连接的问题也提一嘴。无论是Windows还是Linux环境，MySQL的安装包推荐直接从官网下载。装完之后第一件事不是建表，而是确认端口号和连接账号权限。默认端口是3306，如果被占用可以改 my.cnf 或 my.ini 里的 port 参数。远程连接用Navicat、MySQL Workbench这些图形工具，连接前先确认防火墙放行了3306端口，root 用户默认不支持远程连接，需要单独创建账号并授予权限：

sql复制CREATE USER 'app_user'@'%' IDENTIFIED BY 'xxx';
GRANT SELECT, INSERT, UPDATE, DELETE ON school.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

生产环境上千万不要用root账号跑业务，权限做到最小化，这是我在第一家公司学到的最重要的一课。

9. 写在最后：增删改查的真正价值

我从做开发到现在，写过的SQL里90%以上都是增删改查。但即便是这四个基础操作，每一次写得是否规范、是否考虑到并发和数据安全，最后在线上表现出来的差别非常大。我自己有过一次教训：早期做用户积分系统，直接循环执行UPDATE逐条更新积分，结果接口响应时间飙升，数据库CPU接近100%，后来改成了批量UPDATE加事务控制，性能提升了10倍不止。从那以后，我写每条SQL之前都多问自己三个问题：数据范围对不对？并发场景会不会出问题？有没有更好的写法？

最后再贡献一个小技巧：在测试环境做增删改查联调时，给数据库做一个随时可恢复的备份工具脚本是值得的。用 mysqldump 定期备份核心表，出问题可以直接恢复，能省掉很多焦虑。增删改查本身不难，难的是每次操作都带着敬畏心，把边界、异常、性能通通考虑进去。希望这篇内容能帮你把基础打得再扎实一点。