MySQL入门实战：用四大名著英雄表掌握增删改查

如果你的数据库课程刚好进行到第二次作业，题目是“用MySQL创建四大名著英雄表并完成增删改查”，那这一篇应该能帮你少走很多弯路。我在带实训课的时候批过大量同题作业，发现多数同学都能把SQL敲出来，但问到为什么这样建表、为什么字段要写注释、为什么删数据要谨慎，就答不上来了。作业能过，数据库水平却不一定有提升。这篇博文的定位不是应付交差，而是把建表、插数据、查询、更新、删除这条链路完整走一遍，把每个环节背后的设计理由也讲清楚。适合的人：正在学MySQL的初学者、准备复习单表操作的开发者，还有想找一套干净练习数据的朋友。英雄表只有一张，但它能覆盖的知识点，远比你想的多。

1. 四大名著当练习数据：为什么这个设计其实很讲究

1.1 英雄人物的多样性决定了查询练习的上限

很多人第一次看到“四大名著英雄表”会觉得这是个有点幼稚的题目，觉得随便造一套商品表、员工表不是更实用吗？我的看法正好相反。选四大名著是有道理的：16个人物横跨四个完全不同的世界，人物类型足够丰富——关羽是冲锋陷阵的武将，诸葛亮是摇着羽扇的军师，孙悟空是法力无边的神仙，贾宝玉是手无缚鸡之力的贵族公子。

这种多样性对学习SQL非常关键。做查询练习时，战力值从孙悟空9999到林黛玉600，跨越非常大；角色类型有武将、军师、统帅、首领、法师、才女、管家；武器有冷兵器、法宝，也有人干脆没有武器。你会发现，任何常见查询都能在这张表上找到合适的演示场景：按数值筛选、按文本模糊匹配、按分组统计、排序取Top N……一张表就是一个小型业务系统的数据切片。而如果只是abc、123那种纯造数据，你很难记住某一行到底发生了什么，练完就忘。

另外，人物是否熟悉也很重要。你用商品表练SQL，出了bug你可能根本看不出数据对不对；但用武松、林冲、唐僧这些人物，删除一条、改错一个单元格，立刻就能发现，因为你对内容有预期。这对初学者来说是一种近乎免费的校验机制。

1.2 从需求倒推字段：先想清楚要存什么

建表之前不要急着敲CREATE TABLE，先拿张纸列需求——这张表到底要记录英雄的哪些信息？

拿“英雄”这个业务对象来说，常见的需求可以有这些：

• 总得有个唯一标识，否则后面更新、删除都找不到精确目标——这就是主键。
• 英雄名字、别名、出处，这三样是最基础的“身份信息”。
• 性别：方便做群体统计（四大名著里女英雄只有红楼梦的几位，统计效果很直观）。
• 武器或法宝：可以用来练LIKE模糊查询（比如查所有武器带“刀”字的）。
• 角色定位：武将、军师、神仙、才女……这是非常典型的分类字段，分组统计就靠它。
• 战力值：数值型字段，练比较、排序、聚合都靠它。
• 人物简介：可能比较长，适合用TEXT。
• 创建时间：虽然作业里用不上，但真实的业务表几乎都会有“创建时间”字段，可以在这一课就养成习惯。

我把这些需求整理成一张字段设计表，建表时照这个来：

这个设计不算完美，但作为入门练习已经足够。你要是想把表做得更加业务化，可以再拆出“阵营”“年龄”“登场回目”等字段，但对第二次作业来说，上面这些字段能把增删改查的全部语法点都练到，还不会让表复杂到影响理解。

2. 建表语句逐行拆解：注释、字符集和约束一次到位

2.1 前置工作：创建数据库并切换进去

建表之前先做两件事：创建数据库、切换到目标库。很多同学直接建表报了“No database selected”，就是漏了这一步。

CREATE DATABASE IF NOT EXISTS hero_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hero_db;

这里的IF NOT EXISTS是容错写法，库存在就跳过，不会报错。重点是后面两个参数：DEFAULT CHARACTER SET utf8mb4指定了数据库默认字符集，COLLATE是排序规则。为什么必须用utf8mb4？因为它不仅能存中文，还能存生僻字、特殊符号，甚至emoji。老项目里常见的utf8字符集其实也是能存中文的，但在MySQL里utf8最多存3字节，遇到需要4字节的字符就会报错或乱码。新手统一用utf8mb4，基本上不会出乱子。

2.2 四条英雄表建表语句逐段解释

下面是完整的建表语句。我故意把注释COMMENT写得特别“重”，因为第五次、第十次看这张表的人很可能就是你自己——没有注释的建表语句，两周后你就看不懂字段是干什么的了。

CREATE TABLE heroes ( hero_id INT UNSIGNED AUTO_INCREMENT COMMENT '英雄编号，主键，自增', hero_name VARCHAR(50) NOT NULL COMMENT '英雄姓名', alias VARCHAR(50) COMMENT '称号或别称，可为空', book_name VARCHAR(20) NOT NULL COMMENT '出处：三国演义/水浒传/西游记/红楼梦', role_type VARCHAR(20) COMMENT '角色定位：武将/军师/统帅/首领/神仙/法师/贵族公子/才女/管家', weapon VARCHAR(50) COMMENT '武器或法宝，可为空', gender CHAR(2) COMMENT '性别：男/女', combat_power INT UNSIGNED DEFAULT 0 COMMENT '战力值，范围0-9999', description TEXT COMMENT '人物简介', created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间，默认当前时间', PRIMARY KEY (hero_id), UNIQUE KEY uk_name_book (hero_name, book_name) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='四大名著英雄信息表';

逐段看：

整型主键那里，INT UNSIGNED是主键自增里的经典组合。用UNSIGNED可以把取值范围扩展一倍，从有符号的负21亿到正21亿，变成0到42亿。一个英雄表用不了这么大，但主键不需要负数，用UNSIGNED是更严谨的选择。AUTO_INCREMENT会让MySQL自动生成连续的编号，插入数据时不用手工填。

hero_name VARCHAR(50) NOT NULL里的VARCHAR(50)表示最多50个字符，不是50个字节，这个区别后面坑的部分再具体说。NOT NULL表示姓名不能为空，这是业务规则——没有名字的英雄算什么英雄。

alias VARCHAR(50)是别称字段，允许为空。没写别名的英雄，这个字段就是NULL。NULL在查询时要记着用IS NULL判断，不能直接写= NULL，这是SQL新手最容易犯的错误之一。

gender CHAR(2)这里用CHAR而不是VARCHAR。CHAR是定长字符串，长度固定，存“男”或“女”这种长度波动极小的数据效率更好。另一个容易混淆的点是性别字段到底用'男'/'女'还是0/1，都可以，本表用中文是为了查询结果直观，让人一眼就能读懂。

combat_power INT UNSIGNED DEFAULT 0，战力值用整数，默认0。DEFAULT就是在插入时如果没给这个字段值，就用0填空。

description TEXT，TEXT类型用于存储较长的文本，适合放人物简介。TEXT和VARCHAR的边界可以粗略理解为65535字节以内用VARCHAR，超过就要考虑TEXT或更大的类型。

created_at DATETIME DEFAULT CURRENT_TIMESTAMP，插入新行时自动记录当前时间，不用在INSERT里手写时间。很多真实项目的表都有这种字段，越早养成习惯越好。

主键和唯一键是这段建表语句里的核心约束。PRIMARY KEY (hero_id)保证编号唯一、不为空，MySQL会自动为它建索引，后面用WHERE hero_id=某个值做查询时会很快。UNIQUE KEY uk_name_book (hero_name, book_name)是组合唯一键，意思是“同一个出处里，英雄名字不能重复”。这个约束不算绝对严谨（不同故事里同名人物也可能存在），但作为练习题非常合适——它展示了唯一键和主键的区别：主键约束一个表里只能有一个，唯一键可以有多个；唯一键允许NULL，主键不允许。

为什么选InnoDB而不是MyISAM？简单说三点：InnoDB支持事务（可以用BEGIN、ROLLBACK来撤销操作）、支持外键（后续学多表会用到）、行级锁在并发写入时更安全。虽然单表增删改查用不到这些高级特性，但MySQL 8.0里InnoDB就是默认引擎，也是几乎唯一值得选的选择。你不需要花太多时间纠结引擎，记住“InnoDB是默认，也是基准”就行。

2.3 建表后的两个验证习惯

建表语句执行成功后，不要急着直接插数据，先用两条命令做检查：

SHOW CREATE TABLE heroes; DESC heroes;

SHOW CREATE TABLE会展示MySQL实际执行的建表语句，和你写的原语句可能略有差异，但这是表结构的“真实权威版本”；DESC可以快速看字段名、类型、是否允许NULL、有没有默认值。养成建完表先验证的习惯，能避免很多“表建错了，数据已经插进去一半”的尴尬。

3. 插入英雄数据：单行、批量INSERT和绕不开的中文编码

3.1 单行插入：先弄懂字段和值怎么对应

INSERT的写法非常直白：INSERT INTO表名(字段列表) VALUES (值列表)。字段列表和值列表必须一一对应。

INSERT INTO heroes (hero_name, alias, book_name, role_type, weapon, gender, combat_power, description) VALUES ('关羽', '武圣', '三国演义', '武将', '青龙偃月刀', '男', 9600, '蜀汉五虎上将之首，义薄云天');

注意几个细节：

• hero_id没有出现在字段列表里，因为它是AUTO_INCREMENT自增主键，MySQL会自动分配一个编号。
• created_at也没有出现，因为有DEFAULT CURRENT_TIMESTAMP，会自动填当前时间。
• 字符串和日期都要用单引号包起来。MySQL在默认模式下双引号也能用，但养成单引号的习惯更稳妥。
• 数字不用引号，9600直接写数值。

单条INSERT一次只能插一行，如果16位英雄逐条插入要敲16条语句。更高效的做法是在VALUES后面用逗号分隔多组值，一次插完。

3.2 批量插入：一条语句搞定16位英雄

INSERT INTO heroes (hero_name, alias, book_name, role_type, weapon, gender, combat_power, description) VALUES ('张飞', '万人敌', '三国演义', '武将', '丈八蛇矛', '男', 9100, '蜀汉五虎上将之一，勇猛刚烈'), ('诸葛亮', '卧龙先生', '三国演义', '军师', '羽扇', '男', 5500, '智慧的化身，蜀汉丞相'), ('曹操', '魏武帝', '三国演义', '统帅', '倚天剑', '男', 8800, '东汉末年杰出的政治家、军事家'), ('武松', '行者', '水浒传', '步军头领', '雪花镔铁戒刀', '男', 8900, '景阳冈打虎英雄，快意恩仇'), ('林冲', '豹子头', '水浒传', '马军五虎将', '丈八蛇矛', '男', 9300, '八十万禁军枪棒教头，被逼上梁山'), ('鲁智深', '花和尚', '水浒传', '步军头领', '水磨禅杖', '男', 8700, '拳打镇关西，倒拔垂杨柳'), ('宋江', '及时雨', '水浒传', '首领', '朴刀', '男', 4200, '梁山泊总寨主，仗义疏财'), ('孙悟空', '齐天大圣', '西游记', '神仙', '金箍棒', '男', 9999, '七十二变，火眼金睛，大闹天宫'), ('唐僧', '三藏法师', '西游记', '法师', '九环锡杖', '男', 800, '西天取经组织者，慈悲为怀'), ('猪八戒', '天蓬元帅', '西游记', '神仙', '九齿钉耙', '男', 8600, '原是天蓬元帅，取经路上担当开路先锋'), ('沙僧', '卷帘大将', '西游记', '神仙', '降妖宝杖', '男', 7600, '原为卷帘大将，取经路上负责挑担'), ('贾宝玉', '怡红公子', '红楼梦', '贵族公子', '通灵宝玉', '男', 1200, '大观园里的富家公子，叛逆多情'), ('林黛玉', '潇湘妃子', '红楼梦', '才女', '花锄', '女', 600, '才思敏捷，多愁善感的大家闺秀'), ('薛宝钗', '蘅芜君', '红楼梦', '才女', '金锁', '女', 700, '端庄稳重，博学多才的大家闺秀'), ('王熙凤', '凤辣子', '红楼梦', '管家', '无', '女', 1500, '贾府大管家，精明强干，泼辣狠毒');

插完16条后用SELECT * FROM heroes;验证。如果看到的是一个个问号，别慌，大概率是客户端连接字符集的问题，在当前会话执行SET NAMES utf8mb4;再重新查一次，中文通常就回来了。

这个批量写法有个值得注意的点：MySQL的批量INSERT在InnoDB引擎下默认是“要么全成功，要么全失败”的原子操作。本次作业数据量小看不出差别，但数据量大了以后，逐行INSERT的低效和批量INSERT的高效差距会非常明显，现在就记下这个习惯没有坏处。

3.3 不写字段列表的INSERT为什么不推荐

不写字段列表的INSERT也能用：INSERT INTO heroes VALUES (...)，但前提是值列表必须包含表中所有字段，顺序也完全一致。这种写法看起来省事，实际上隐患很大：一旦表结构调整过（加了字段、换了顺序），INSERT就会错位甚至失败。我的建议是：只要往表里写数据，永远显式写出字段列表。这个习惯越早养成越好，真实项目和面试里都有一堆人在这个细节上翻过车。

4. SELECT查询篇：从“读数据”到“读有效信息”

4.1 全表查询和字段筛选：SELECT * 是起点不是终点

SELECT * FROM heroes;能查出全部16行所有字段，练习时最直观。但生产中要尽量避免SELECT *，原因很实际：数据量大时全字段查询浪费带宽，而且会查出根本用不到的列。更重要的是SELECT *隐藏了代码意图，阅读者看不到到底需要哪些字段。

练习时定期用明确字段代替星号：

SELECT hero_name, book_name, combat_power FROM heroes;

这一条只取三列，输出更干净，也更快养成“按需取列”的意识。

4.2 条件查询：WHERE才是单表操作的核心

WHERE是所有增删改查里“查、改、删”的公共地基，因为UPDATE和DELETE最终靠的也是WHERE精确锁定行。先看最基本的比较筛选：

-- 战力超过8800的英雄 SELECT hero_name, book_name, combat_power FROM heroes WHERE combat_power > 8800; -- 三国演义里的男性武将 SELECT hero_name, role_type, weapon FROM heroes WHERE book_name = '三国演义' AND role_type = '武将'; -- 武器名里带“刀”的英雄（中文模糊查询实战） SELECT hero_name, weapon FROM heroes WHERE weapon LIKE '%刀%'; -- 出处属于三国演义或水浒传的英雄 SELECT hero_name, book_name FROM heroes WHERE book_name IN ('三国演义', '水浒传');

这里有几个值得展开的细节。AND和OR可以组合多个条件，但AND优先级高于OR，混用时一定要用括号明确分组，否则结果可能和你想的完全不一样。比如“三国演义中的武将或战力9000以上”如果不加括号，写成WHERE book_name='三国演义' AND role_type='武将' OR combat_power>9000，会变成“三国演义的武将 + 所有书里战力9000以上的人”，结果直接跑偏。

LIKE '%刀%'里的%是通配符，表示任意长度的任意字符。放在前后就是只要中间含“刀”就算。下划线_表示单字符，比如'孙_空'能匹配“孙悟空”（孙后面一个字符再空），但不匹配“孙大圣”。百分号配合下划线能玩出很多模糊查询效果，要注意的是%越多，查询越难走索引，大表上要小心。

IN (...)相当于连续多个OR条件的简写，代码可读性好很多。

4.3 排序、去重、限量：让结果真正有用起来

数据读出来之后，最常做的事情就是排序和限量：

-- 战力从高到低排序，取前5名 SELECT hero_name, combat_power FROM heroes ORDER BY combat_power DESC LIMIT 5; -- 同一本书内部的英雄按战力降序排列 SELECT book_name, hero_name, combat_power FROM heroes ORDER BY book_name ASC, combat_power DESC;

ORDER BY的ASC表示升序（默认），DESC表示降序。多字段排序的规则是：先按第一个字段排，第一个字段相等时才比较第二个字段。

去重用DISTINCT，比如想知道四大名著素材里涉及几本书：

SELECT DISTINCT book_name FROM heroes;

LIMIT则用于限制返回行数，分页常用。LIMIT 5就是只返回前5行，LIMIT 10, 5表示跳过10行后再取5行，分页场景里这个写法很常见。

4.4 聚合统计：从一行一行看到整体画像

单表查询里最能体现“信息密度”的是聚合函数加GROUP BY。建议把这几个函数逐个试一遍：COUNT（计数）、AVG（平均）、MAX（最大）、MIN（最小）、SUM（求和）。

SELECT book_name, COUNT(*) AS hero_count, ROUND(AVG(combat_power), 1) AS avg_power, MAX(combat_power) AS max_power FROM heroes GROUP BY book_name;

这条语句的输出会按四本书分组，每本书一行，统计出每个阵营的英雄数量、平均战力、最高战力。你甚至能直观看到：西游记平均战力被唐僧拉低了多少，红楼梦整体战力垫底。

GROUP BY的核心逻辑是“分组之后再聚合”。这里有一个非常经典的坑：一旦用了GROUP BY，SELECT后面出现的非聚合字段，理论上必须是分组字段本身，否则在严格模式的MySQL 8.0里会直接报错或返回不可预期的值。比如SELECT hero_name, COUNT(*) FROM heroes GROUP BY book_name;里的hero_name就和分组无关，不应该出现。初学阶段，先记住“GROUP BY后面的字段，和SELECT里的分组字段保持一致”这个最小法则。

分组之后如果还想过滤，不能再用WHERE，得用HAVING。WHERE过滤的是行，HAVING过滤的是分组。比如想找平均战力超过3000的出处：

SELECT book_name, AVG(combat_power) AS avg_power FROM heroes GROUP BY book_name HAVING AVG(combat_power) > 3000;

WHERE和HAVING的区别是SQL入门一个高频考点，拿这张英雄表多试几次，印象会比背定义深刻得多。

5. 修改与删除：操作前必须想清楚WHERE，不然就是灾难

5.1 UPDATE：先精确锁定，再动手改

UPDATE的基本语法是UPDATE表名SET字段=新值WHERE条件。第一次用，建议先选一个最熟悉的人试验：

UPDATE heroes SET combat_power = 9400 WHERE hero_name = '关羽';

这条语句把关羽的战力从原来的9600改成9400。WHERE条件是“精确到英雄名”，因为表里有组合唯一键uk_name_book，同一个出处里英雄名不会重复，所以这条WHERE能精准命中。这是建表时设计唯一键的价值之一。

UPDATE可以一次更新多个字段，中间用逗号隔开：

UPDATE heroes SET combat_power = 9400, weapon = '青龙偃月刀（赤兔赠）' WHERE hero_id = 1;

也可以按条件批量更新。比如觉得“法师”角色整体战力偏低，统一上调：

UPDATE heroes SET combat_power = combat_power + 500 WHERE role_type = '法师';

SET里可以用原来的值参与计算，这是UPDATE里很实用的小技巧：combat_power = combat_power + 500表示在原有数值上加500。

5.2 漏写WHERE的灾难：全表更新有多可怕，以及怎么兜底

最危险的一个场景：想更新林黛玉的战力，手一抖，写成了：

UPDATE heroes SET combat_power = 0;

你收到了“Query OK, 16 rows affected”。16行，全部被清零了，因为没写WHERE。这是所有MySQL新手（甚至不少工作一两年的开发）都犯过的错误。一旦发生，轻则尴尬，重则生产事故。

怎么减少损失？三招配合用。

第一，养成“先SELECT后UPDATE”的习惯。执行UPDATE之前，先跑一遍同样WHERE条件的SELECT，确认要影响的行数是预期的：

SELECT hero_id, hero_name, combat_power FROM heroes WHERE hero_name = '林黛玉';

第二，利用事务。InnoDB支持事务回滚，这是它比MyISAM强的地方。操作前开启事务，发现问题直接回滚：

BEGIN; UPDATE heroes SET combat_power = 0; -- 发现误操作，赶紧回滚 ROLLBACK;

如果是正常的批量修改，最后用COMMIT提交。只要没COMMIT，ROLLBACK就能把数据恢复原样。要注意的是，MySQL里的DDL语句（CREATE、ALTER、DROP、TRUNCATE）是隐式提交的，事务只能保护INSERT、UPDATE、DELETE这类DML操作。

第三，如果你的图形化工具（比如Navicat或DataGrip）有“安全模式”或“SQL编辑预防”选项，建议打开。这类工具会在UPDATE或DELETE语句缺少WHERE时二次确认。但切记：工具只是辅助，真正可靠的是自己把WHERE写正确。

5.3 DELETE：三种删除方式的取舍

删除数据有三种手段，经常被混为一谈，但语义完全不同：

-- 删除指定的某行或某几行 DELETE FROM heroes WHERE hero_name = '贾宝玉'; -- 清空表数据，但保留表结构 TRUNCATE TABLE heroes; -- 连表带结构一起删除 DROP TABLE heroes;

第一句DELETE FROM heroes WHERE hero_name = '贾宝玉';只删除指定行。用WHERE精确锁定，风险和UPDATE一样——漏写WHERE，DELETE FROM heroes;会把表中所有行都删掉。所以“先SELECT后DELETE”的规则同样适用：

SELECT * FROM heroes WHERE hero_name = '贾宝玉'; -- 先确认只有1行 DELETE FROM heroes WHERE hero_name = '贾宝玉'; -- 再删

TRUNCATE和DELETE的差别用表格列一下，方便对比记忆：

对于本次作业，你可能只想删掉某一两行测试数据，那用DELETE足矣。TRUNCATE在“想彻底清空重来”时最有用。

DROP TABLE heroes;则是整张表都没了，结构、数据、索引一起消失。执行之前务必确认：我要的真的是删表吗？见过太多同学想把表清空重做，结果一条DROP下去，之前精心设计的字段结构全部归零，只能重头建表。如果只是清数据，用TRUNCATE；只有确定不再需要这张表，才用DROP。

还有一个很多人不解的现象：DELETE删掉hero_id最大的那行后，再INSERT一个新英雄，新英雄的编号不是“补位”而是继续递增。比如删掉了hero_id=16的王熙凤，下次插入的新行编号是17。这是AUTO_INCREMENT的机制：它只用不回头，删掉的行号不会复用。这不算bug，但如果你期待ID连续，看到中间缺号千万别慌，数据没有丢，只是自增序列本来就允许有空洞。

6. 这门作业里最容易翻车的6个坑，逐个过一遍

6.1 没有USE数据库，直接在默认库里建表

现象：CREATE TABLE heroes;执行报错“ERROR 1046 (3D000): No database selected”。原因很简单，MySQL不知道你要把表建在哪个数据库里。解决：先执行USE hero_db;再建表。如果建表时想一步到位，也可以写CREATE TABLE hero_db.heroes (...)，但作业阶段还是老老实实两步走，顺便练习USE的用法。

6.2 中文变问号或乱码

现象：SELECT出来的中文是???，或者插入时直接报“Incorrect string value”。这种问题在作业里见到的频率稳居前三。根本原因是三层字符集没对齐：数据库字符集、客户端连接字符集、终端显示字符集。最简单的排查顺序：确认建库时写了utf8mb4；确认连接后执行过SET NAMES utf8mb4;；如果在Windows命令行，还需要执行chcp 65001把终端切到UTF-8编码。挨个检查，中文乱码基本都能解决。

6.3 字符串不加引号，数字加引号

有人把数字字符混写。正确规则是：字符类型和日期类型要用单引号，数值类型不要加引号。如果你给VARCHAR字段的hero_name传一个不带引号的关羽，MySQL会把关羽当成字段名或函数名去解析，直接报Unknown column。反过来，把战力值写成'9600'虽然也能插入，但数字带引号会被隐式转成字符串，在某些比较场景下会影响索引使用和排序结果。从练习阶段就保持类型严格一致，省得后面踩隐式类型转换的坑。

6.4 字段名撞上保留字或内置函数名

MySQL里有一批保留字不能裸用做字段名，比如order、group、desc、level、rank、condition。有人建表时顺手把战力字段叫做rank，结果SELECT rank FROM heroes;直接语法报错。解决办法两种：一是换名字，把rank改成combat_power，这是最好的办法；二是加反引号，写成rank，但每次写SQL都要带反引号，非常麻烦。我的建议永远是换字段名，别和保留字硬刚。这也是建表前设计字段清单的价值——很多字段名问题在设计阶段就能规避。

6.5 批量插入数据错位

批量INSERT如果不写字段列表，VALUES的顺序必须和表字段完全一致。很多人手动加了字段后忘了同步INSERT语句，数据插进去顺序全乱，比如把武器填进了别名列。解决方式前面已经提过：写INSERT永远带字段列表。另一个相关的坑是VARCHAR长度写得太小，比如hero_name用VARCHAR(5)，插入“孙悟空”没问题，但“唐僧”也3个字符，勉强够用，可一旦想插入“齐天大圣”这类4字以上内容，5长度就不够了。真正要理解的是VARCHAR(50)和VARCHAR(5)的差距不只是存储大小，更决定了数据的可容纳性。人物名字虽然短，但真实系统里的用户名、订单编号往往需要预留长度，所以字段长度别抠门。

6.6 增删改之后不验证结果

做增删改查作业时，最常见的“隐形翻车”不是SQL报错，而是SQL执行成功但结果和预期不符。执行INSERT、UPDATE、DELETE之后，一定要用SELECT把受影响的数据重新查出来看一眼。比如改关羽的战力，很多人执行完UPDATE就交作业了，完全没检查，结果因为WHERE条件写成hero_name='关公'，根本没匹配到行，MySQL还不报错，只会提示“Query OK, 0 rows affected”。看到0 rows affected就要警惕：你的WHERE是不是没匹配到任何数据？条件写错还是数据本身就没有？这个检查习惯放在真实开发里，比多会两条SQL语法重要得多。

到这里，建表、插数据、查询、修改、删除这条链路算是完整走了一遍。我个人的体会是：单表增删改查虽然只是MySQL的入门部分，但它锻炼的不只是SQL语法，更是“先设计再动手、操作前先想清楚WHERE会影响的边界”这两个习惯。一旦建立，后面学JOIN、学索引、学事务都会顺很多。做完这次的英雄表作业后，可以试试再建一张“兵器谱”，字段设计成兵器名称、持有英雄、出处、威力值，用英雄id和兵器表做关联练习的铺垫。等到第三次作业讲到多表查询时，你会发现今天这些数据已经提前帮你铺好了路。