MySQL CRUD（上）：建表、插入与查询的硬核实践指南

1. 建表之前，先想明白CRUD到底在操作什么

很多人刚接触MySQL时，会把CRUD理解成“增删改查”四个单词，然后迫不及待地打开命令行敲INSERT、SELECT、UPDATE、DELETE，敲完发现能跑通，就觉得自己会了。但真到了实际项目里，一个简单到只有两张表的业务模块，都可能把新人卡到怀疑人生。原因很简单：CRUD不是四条SQL语法，而是围绕“数据生命周期”展开的一整套设计思路。

Crud的四个字母对应Create（新增）、Read（查询）、Update（修改）、Delete（删除），这套操作的完整流程，就是一条数据从出生到退休的一生。你写注册功能时，用户数据是Create；你打开订单列表时，订单数据是Read；你改收货地址时，地址数据是Update；你清理测试数据时，那些脏数据是Delete。任何一个业务系统，本质上都是这四种操作在不同表、不同数据之间的循环往复。

这一篇“MySQL：CRUD（上）”主要聚焦在Create和Read上，因为这两块是基础中的基础。Update和Delete虽然语法简单，但牵扯到事务隔离、锁机制、批量操作等更复杂的知识，放到下一篇单独讲。先把“写入”和“查询”吃透，后面再学更新和删除会轻松很多。

顺便说一句，很多同学在学CRUD之前，卡在了MySQL安装这一步。如果你也是刚装好MySQL，连命令行都还没进去过，本篇的章节会配合环境准备讲清楚。如果你已经在用Navicat或MySQL Workbench这类图形工具，那操作会更直观，但原理是一样的，建议还是跟着命令行走一遍，因为图形工具隐藏了很多细节，出了问题你根本不知道去哪排查。

2. CREATE阶段的硬核细节：建库、建表、写数据

2.1 建库建表：先规划，再动手

我见过太多人上来就写CREATE DATABASE，然后马上建表、插数据，等写到第20行突然发现字段类型不对，又回头DROP TABLE重来。这种“先跑了再说”的思路，在做练习时无所谓，但一旦表里有了核心业务数据，改表结构带来的风险和成本就完全不一样了。

建库建表之前，至少要回答三个问题：这个表属于哪个业务模块？这条数据有哪些核心属性？这些属性之间是什么关系？

在MySQL里，建库的SQL很简单：

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

这里我强烈建议默认字符集用utf8mb4，而不是老旧的utf8。为什么？因为utf8在MySQL里最多存3个字节，Emoji表情和一些生僻汉字需要4个字节，用utf8存这些数据会直接报错。而utf8mb4完全兼容utf8，还能存表情，是当前最稳妥的选择。我在2018年接手过一个老项目，全库都是utf8，用户一输入“”类表情就变问号，后来全库改utf8mb4，折腾了一整天才改完。

collation（排序规则）我习惯用utf8mb4_unicode_ci，它对大小写不敏感，匹配时更宽松。如果业务上有特殊的排序要求，比如需要区分大小写，可以用utf8mb4_bin。

接下来建表，拿一个经典的“学生课程成绩”场景举例：

sql复制USE school;

CREATE TABLE student (
    student_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT '学生ID',
    student_name VARCHAR(50) NOT NULL COMMENT '学生姓名',
    gender ENUM('M', 'F') DEFAULT 'M' COMMENT '性别',
    birth_date DATE COMMENT '出生日期',
    phone VARCHAR(20) UNIQUE COMMENT '手机号',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生信息表';

CREATE TABLE course (
    course_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT '课程ID',
    course_name VARCHAR(100) NOT NULL COMMENT '课程名称',
    credit TINYINT UNSIGNED DEFAULT 2 COMMENT '学分'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';

CREATE TABLE student_course (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    student_id INT UNSIGNED NOT NULL COMMENT '学生ID',
    course_id INT UNSIGNED NOT NULL COMMENT '课程ID',
    score DECIMAL(5,2) COMMENT '成绩',
    UNIQUE KEY uk_student_course (student_id, course_id),
    CONSTRAINT fk_sc_student FOREIGN KEY (student_id) REFERENCES student(student_id),
    CONSTRAINT fk_sc_course FOREIGN KEY (course_id) REFERENCES course(course_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课成绩关联表';

这套设计几乎是教科书式的：student和course是基础表，student_course是关联表，通过外键把多对多关系拆成两个一对多。这里有几个关键点：

• INT UNSIGNED：正整数的最大值翻倍到42亿，主键一般用不到负数，所以没必要浪费一半取值范围。
• AUTO_INCREMENT：自增主键。注意，自增列必须是索引，通常是主键。
• DECIMAL(5,2)：成绩最多5位数字，其中2位小数，范围是-999.99到999.99，完全够用。千万别用FLOAT存金额、成绩这类需要精确的值，浮点数在计算机里是近似存储，0.1+0.2可能等于0.30000000000000004。
• ENUM类型不建议大规模使用，它修改枚举值非常麻烦，而且不同版本MySQL对非法值的处理不一致。能用TINYINT加注释替代的，尽量别用ENUM。
• UNIQUE KEY uk_student_course (student_id, course_id)：这是联合唯一索引，确保同一个学生选同一门课只能有一条记录，这是业务层面的硬约束。

以上设计不是唯一的答案，但它保证了数据的完整性和可扩展性。你以后在这个基础上加“成绩录入时间”“考试批次”“任课教师”，都不用在表结构上做伤筋动骨的改动。

2.2 INSERT的三种姿势，你真的用对了吗

建好表之后，写入数据是第一个动手环节。MySQL里INSERT无非三种语法，但每种用在哪、什么时候用错会出事，很多工作两三年的开发也未必捋得清。

第一种，也是最常用的标准单行插入：

sql复制INSERT INTO student (student_name, gender, birth_date, phone) 
VALUES ('张三', 'M', '2003-05-12', '13800001111');

注意，这里我没有写student_id和created_at，因为前者自增，后者有DEFAULT CURRENT_TIMESTAMP。指定字段名的好处是：即使表结构增加了新列，这条INSERT也不会报错；并且你清清楚楚知道每个值对应哪个字段，不用去数VALUES里第几个位置是哪个列。

第二种，多行插入：

sql复制INSERT INTO student (student_name, gender, birth_date, phone) VALUES
('李四', 'F', '2003-08-20', '13800002222'),
('王五', 'M', '2003-02-14', '13800003333'),
('赵六', 'F', '2003-11-30', '13800004444');

一次INSERT插入多行，比循环执行多次单行INSERT性能高得多。在InnoDB存储引擎下，一条多行INSERT是一个事务，而循环单行INSERT默认是每条语句一个自动提交事务，等于反复刷磁盘日志。插入1万条数据时，多行插入可能只要1秒，循环插入可能得跑20秒。实测差距非常夸张。

第三种，INSERT ... SET语法：

sql复制INSERT INTO student SET student_name='钱七', gender='M', birth_date='2003-01-01';

这种写法MySQL和MariaDB都支持，但它不是标准SQL，使用面较窄。我平时几乎不用它，因为它在可读性和可维护性上并没有比第一种更优，遇到批量插入的场合还写不了。

有一个高频面试题：“插入时主键冲突怎么办？”MySQL给了三种处理办法：

sql复制-- 冲突后直接更新
INSERT INTO student (student_id, student_name) VALUES (1, '张三改') 
ON DUPLICATE KEY UPDATE student_name = VALUES(student_name);

-- 或者冲突后什么都不做
INSERT IGNORE INTO student (student_id, student_name) VALUES (1, '张三改');

-- 或者冲突后替换整行
REPLACE INTO student (student_id, student_name) VALUES (1, '张三改');

这三者一定要分清楚。INSERT IGNORE适合“数据存在就跳过，不存在才插入”的去重场景；ON DUPLICATE KEY UPDATE适合“有就更新、没有就插入”的upsert场景，比如积分流水、计数器累加；而REPLACE INTO要注意，它遇到主键冲突时会先DELETE旧行，再INSERT新行，表面上看着是更新，实际上会触发删除操作，如果你有外键关联或者表上删数据会走触发器，REPLACE INTO会重新执行一遍删除插入流程，极易出问题。老项目里那些用REPLACE INTO做更新的代码，我基本都建议改掉。

2.3 字符集乱码和自增ID跳跃：写入时的隐形炸弹

写入数据时，最容易让新人一脸懵的两个问题就是乱码和自增ID不连续。

乱码问题，90%出在连接层，而不是表结构。你表结构设置了utf8mb4，但你的客户端连接用的还是latin1，那写入的中文到库里已经变成了乱码，事后怎么查都是错的。解决方法是连接后立刻执行：

sql复制SET NAMES utf8mb4;

SET NAMES本质是告诉服务器“我这边的客户端发来的和想收的都是什么字符集”，它会同时设置character_set_client、character_set_connection和character_set_results三个变量。各种图形工具一般默认已经处理了这个问题，但你用命令行敲SQL，或者通过JDBC连数据库，一定要确保连接串里也指定了characterEncoding=utf8mb4或utf8。

还有一个鲜为人知的坑：MySQL命令行的--default-character-set参数。Windows的CMD默认使用GBK编码，如果你的SQL文件是UTF-8保存的，直接在CMD里用source导入文件，中文就全毁了。正确做法是：

bash复制mysql -uroot -p --default-character-set=utf8mb4 school < data.sql

Linux下从终端粘贴SQL也一样，先检查终端编码，再决定加不加这个参数。

自增ID跳跃也是一个容易让新人抓狂的现象。你往表里插入一条数据，然后删掉，再插一条，发现ID变成了2，而不是1。这是正常的。InnoDB的自增主键不会因为删除了某行就回退，因为同一时刻可能有其他事务已经分配了ID=2，回退会造成冲突。还有更常见的场景，INSERT失败也会消耗自增ID，比如唯一键冲突，尽管数据没插进去，但这个ID已经被取走了。

所以，你的业务逻辑千万不要假设主键是连续的。主键只保证唯一且递增，不保证中间没有空缺。如果业务上需要“第几条记录”这种序号，应该在查询时用ROW_NUMBER()窗口函数去算，而不是依赖自增主键。

3. SELECT的多种打开方式：查询不只是“SELECT * FROM”

3.1 基础查询和WHERE过滤：先学会缩小范围

很多新人写查询，最顺手的就是SELECT * FROM student，一选就把整个表全拉出来。练习可以，但生产环境这么写，往往会被DBA约谈。为什么？两个原因。第一，SELECT *会把你根本不需要的字段也读出来，增加网络传输和内存开销；表字段越多，浪费越大。第二，如果表结构后面加了TEXT类型的字段，哪怕你只查两个字段，也会被迫把大字段也读出来，IO开销直接就上去了。

正确的习惯是，只查你真正需要的字段：

sql复制SELECT student_id, student_name, birth_date FROM student;

然后是WHERE过滤。WHERE的本质是“逐行筛选”，它的写法决定了MySQL能不能走索引，能不能减少扫描量。举个例子，查所有2003年出生的学生，新手可能会写：

sql复制SELECT student_id, student_name FROM student WHERE YEAR(birth_date) = 2003;

这个语句虽然能查出来，但它在birth_date上做了函数运算，导致MySQL无法使用birth_date这个字段上的索引，只能全表扫描。如果表里有100万条数据，这个查询可能慢好几倍。更优的写法是把它转成范围查询：

sql复制SELECT student_id, student_name FROM student 
WHERE birth_date >= '2003-01-01' AND birth_date < '2004-01-01';

这种写法能用上索引，因为birth_date本身就是日期类型，范围比较可以直接走B+树索引定位。所以，以后写WHERE时多问自己一句：这个条件是不是让字段“裸奔”了？

另外，多个过滤条件之间，AND的优先级高于OR。这个细节特别容易出错。比如你想查“性别为男的学生，或者名字叫张三的学生”，新手写：

sql复制SELECT * FROM student WHERE gender = 'M' OR student_name = '张三' AND created_at > '2023-01-01';

这条SQL会被解析成：gender='M' OR (student_name='张三' AND created_at > ...)。如果这不是你想要的，必须加括号：

sql复制SELECT * FROM student WHERE (gender = 'M' OR student_name = '张三') AND created_at > '2023-01-01';

3.2 排序、去重和LIMIT分页的实战细节

排序用ORDER BY，默认是升序（ASC），降序要指定DESC。最常见的一个坑是：多个字段排序时，每个字段后面的方向必须单独写。比如先按性别升序，再按出生日期降序：

sql复制SELECT student_id, student_name, gender, birth_date 
FROM student 
ORDER BY gender ASC, birth_date DESC;

如果你写成ORDER BY gender, birth_date DESC，MySQL会理解为gender升序、birth_date降序，因为gender后面没写方向，默认就是升序。这勉强算一个设计上的小陷阱，但很多人会以为“只有一个DESC全局生效”，结果排序结果完全不对。

去重用DISTINCT。注意，SELECT DISTINCT student_name, gender FROM student是对“student_name和gender的组合”去重，而不是只对student_name去重。这个区别很关键，别等数据返回了才发现自己想要的去重效果根本没实现。

LIMIT分页是查询中绕不开的环节。基本写法：

sql复制SELECT student_id, student_name FROM student ORDER BY student_id LIMIT 20, 10;

这个SQL的含义是从第21条开始取10条，也就是第3页的数据。但数据库实现上，LIMIT 20, 10不是直接“跳到第21条”，而是先扫描前20条，再把它们丢弃，最后返回10条。当页数特别深时，比如LIMIT 100000, 10，MySQL可能要先扫10万行再丢弃，性能极差。

深度分页的优化方案有很多，最简单实用的就是用“上一页最后一条ID”来替代偏移量：

sql复制SELECT student_id, student_name FROM student 
WHERE student_id > 100000 
ORDER BY student_id 
LIMIT 10;

这样MySQL能直接通过主键索引定位，完美绕开偏移扫描。很多高并发的业务系统，比如社区APP的帖子列表，用的就是这个思路。当然，如果你一定要用偏移分页，并且数据量不大，就不用考虑这些了。

3.3 聚合查询：COUNT、SUM、AVG背后的隐式规则

我见过不少开发在统计需求量突然上来时，才开始学习GROUP BY，结果写出来的SQL要么报错，要么统计结果不对。聚合查询远不止“把多条数据合成一条”这么简单。

拿我们那个“学生课程成绩”库来举例。统计每个学生的选课数量，或者平均分，就是标准的GROUP BY场景：

sql复制SELECT 
    student_id, 
    COUNT(course_id) AS course_count, 
    AVG(score) AS avg_score,
    MAX(score) AS max_score,
    MIN(score) AS min_score,
    SUM(credit) AS total_credit
FROM student_course sc
JOIN course c ON sc.course_id = c.course_id
GROUP BY student_id;

这里有一个非常经典的SQL模式问题：SELECT里出现的非聚合字段，必须出现在GROUP BY里。比如上面的SELECT里有student_id，那GROUP BY后面也必须有student_id。这是标准SQL的规则，MySQL在5.7版本之前默认没这么严格，你查一个不在GROUP BY里的字段，它可能“聪明地”帮你选一行返回，但这行数据到底是不是你想要的，完全取决于查询计划。5.7之后，ONLY_FULL_GROUP_BY默认开启，不遵守规则的SQL会直接报错。

有人会说：“我只想查出每个学生的name和平均分，但name不是聚合字段，又不想在GROUP BY里加它，怎么办？”解法是在student_id已经唯一的情况下，把name也加进GROUP BY：

sql复制SELECT student_id, student_name, AVG(score)
FROM student_course 
JOIN student ON student_course.student_id = student.student_id
GROUP BY student_id, student_name;

虽然看起来冗余，但逻辑上没毛病，而且能走联合索引的话性能也不差。

另一个常见的需求是：查询平均分大于等于80分的学生。这时候新手容易直接写：

sql复制SELECT student_id, AVG(score) AS avg_score 
FROM student_course 
GROUP BY student_id 
WHERE AVG(score) >= 80;

这句SQL会报错。因为WHERE是在分组前执行的，它无法引用聚合函数。要去掉平均分低于80的组，必须在GROUP BY之后用HAVING：

sql复制SELECT student_id, AVG(score) AS avg_score 
FROM student_course 
GROUP BY student_id 
HAVING AVG(score) >= 80;

执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。把这条执行顺序记牢，你写大部分SQL时脑子里都有画面了。WHERE负责在分组前过滤行，HAVING负责在分组后过滤组，这个顺序千万别搞反。

3.4 多表查询：JOIN的底层逻辑和取舍

项目里的大部分查询都不是单表，而是多表关联。JOIN就是把多张表的数据按某种关系拼在一起。

最常见的INNER JOIN，只看两张表都匹配得上的记录。比如查询选了课程的学生以及课程名：

sql复制SELECT s.student_name, c.course_name, sc.score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
JOIN course c ON sc.course_id = c.course_id
WHERE s.student_id = 1;

先用小表（某条学生记录）作为驱动表，再通过索引去另外两张表里找匹配记录，这就是典型的Nested Loop Join流程。实际优化器考虑的因素很多，但核心思想是一致的：小表驱动大表，被驱动表的关联字段必须建索引。

LEFT JOIN是左外连接，它会把左表的记录全部保留，右表没有匹配的字段置NULL。比如我想查出所有学生的选课情况，没选课的也要显示：

sql复制SELECT s.student_name, sc.score
FROM student s
LEFT JOIN student_course sc ON s.student_id = sc.student_id
ORDER BY s.student_id;

如果某个学生没选课，他的score就是NULL。这时要注意，筛NULL不能写= NULL，必须用IS NULL或IS NOT NULL。因为NULL表示“未知”，任何和NULL做等值比较的结果都是“未知”，既不true也不false。这也是SQL面试的万年考点。

写JOIN时还有个容易踩的坑是关联条件缺失。如果你写：

sql复制SELECT s.student_name, c.course_name
FROM student s, course c;

这是MySQL老式写法，等价于CROSS JOIN笛卡尔积。如果student有100条，course有50条，结果就返回5000条。早期有人写多表查询忘了加WHERE关联条件，就是在生产环境造了一个笛卡尔积，直接把数据库IO打满。所以现在行业里更推荐用显式的JOIN ... ON写法，因为ON条件强制约束了关联关系，能有效降低这类事故概率。

4. 查询性能的生命线：索引，你在用什么姿势看数据

4.1 索引为什么能快，以及它的底层数据结构

索引是MySQL查询性能的核心，这一节我尽量用大白话讲清楚，同时保留足够的深度。

你可以把索引想象成书的目录：没有目录的时候，你想找一个成语得从头翻到尾，这叫全表扫描；有了目录，你直接按拼音翻到那一页，这叫索引查找。MySQL里InnoDB默认用的索引结构是B+树。B+树和普通二叉树不同，它是一个多叉平衡树，每个节点能存多个键值，树的高度非常低。一张几百万行的表，B+树可能只有三层高。这就意味着，你要找到一条记录，最多只需比较三次左右，就能从根节点走到叶子节点。

第一层是根节点，第二层是中间节点，第三层才是叶子节点。InnoDB的叶子节点上直接存的就是整行数据（聚簇索引），或者存了主键值（二级索引）。所以在InnoDB里，通过主键查询是最快的，一步到位，不需要回表。

二级索引就是你在其他字段上创建的索引。二级索引的叶子节点不存完整行数据，而是存主键值。比如你在student_name上建了索引，查询SELECT * FROM student WHERE student_name='张三'时，先用二级索引找到主键值，再用主键值回聚簇索引查完整行，这叫“回表”。如果查询只需要student_name和主键，那么二级索引里已经有这两个字段了，根本不需要回表，这叫“覆盖索引”，性能最优。

4.2 主键选择、最左前缀原则和索引失效的坑

主键的选择直接决定了整张表的结构。InnoDB的聚簇索引就是主键索引，如果你没有显式定义主键，InnoDB会找一个非空的唯一索引作为聚簇索引；如果也没有，它会生成一个隐藏的ROWID作为聚簇索引。所以，每张表最好都显式定义一个主键。

主键建议用自增INT，或者是无序的UUID。为什么自增更好？因为新插入的行主键值比之前的大，B+树会直接往右追加，不需要频繁调整树的平衡结构。而UUID是随机的，新ID可能落在树的中间位置，导致页分裂和碎片化，写入性能会有明显下降。

联合索引有个非常重要的规则：最左前缀原则。比如你建了联合索引(student_id, course_id)，MySQL会先按student_id排序，同student_id之间再按course_id排序。这样一个索引能支持以下查询：

• WHERE student_id = 1
• WHERE student_id = 1 AND course_id = 2

但不能支持WHERE course_id = 2，因为跳过了索引最左列，MySQL无法直接定位到范围。所以，建联合索引时，字段顺序至关重要。区分度高的、经常用于等值查询的字段放左边；范围查询的字段放右边，通常也能利用索引。

索引失效是个高频问题，常见场景有：

• 对索引列使用函数，如WHERE YEAR(birth_date)=2003，索引失效。
• 对索引列做隐式类型转换，比如字段是字符串类型，你查WHERE phone = 13800001111，MySQL会把字符串隐式转成数字，索引失效。
• 使用LIKE '%xx'前导通配符，索引失效；但LIKE 'xx%'后导通配符可以用索引。
• OR连接的两个条件中，只要有一个字段没索引，整个查询可能退化成全表扫描。

这些坑不需要死记，关键是理解索引的结构。你想让MySQL用上索引，就得保证它能在B+树上按顺序定位，任何打破顺序的操作都会让索引失去意义。

4.3 EXPLAIN查看执行计划：学会让SQL说话

当你觉得某条SQL慢时，第一个动作不是加内存，也不是换数据库，而是用EXPLAIN看它到底是怎么执行的。

sql复制EXPLAIN SELECT s.student_name, c.course_name, sc.score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
JOIN course c ON sc.course_id = c.course_id
WHERE s.student_id = 1;

EXPLAIN结果里关键的字段有：

• type：访问类型。性能从好到差依次是system > const > eq_ref > ref > range > index > ALL。ALL就是全表扫描，出现在关键查询里基本意味着要优化了。
• key：实际用到的索引名，如果为NULL，说明没走索引。
• rows：预估扫描的行数，这个数字越大，说明代价越高。
• Extra：如果出现Using temporary或Using filesort，说明SQL用了临时表或文件排序，往往可以通过优化索引避免；如果出现Using index，说明走了覆盖索引，是最好的情况。

比如，如果查询只查了student_id和student_name，而student_name上有二级索引，EXPLAIN可能出现Using index，那么MySQL根本不需要回表，性能会非常快。

我见过不少刚入职的开发，一被问优化就说“加索引”，但加了索引以后有没有生效，根本解释不清楚。用EXPLAIN跑一遍，一切一目了然。以后优化SQL，别拍脑袋，先看执行计划。

5. 实操实录：从零跑通一次完整的Create和Read流程

5.1 本地MySQL环境准备（含Windows和Linux）

这一节写给还没装好MySQL的同学。官方下载地址的安装包其实很简单，但网上很多教程把步骤写得很绕，这里给你一条最简单的路。

Windows环境，直接去MySQL官网下载MySQL Installer for Windows。下载时选“MySQL Community Server”，一路Next安装，装到“Select Products and Features”界面时，把MySQL Server 8.0选上，其他工具比如MySQL Workbench可以看自己需要。安装过程中会让你设置root密码，建议用一个专门的测试密码，别用系统登录密码。端口默认3306，不用改。装完以后，在Windows服务里确认MySQL服务已经启动，再把MySQL的bin目录加到环境变量PATH里，打开CMD输入mysql -uroot -p，输入密码进到mysql>提示符就成功了。

Linux环境，以Ubuntu为例：

bash复制sudo apt update
sudo apt install mysql-server
sudo systemctl start mysql
sudo systemctl enable mysql
sudo mysql_secure_installation

Ubuntu安装的MySQL root用户默认使用auth_socket认证，直接用sudo mysql就能进，不需要密码。如果你想用密码登录，需要手动改一下认证插件：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

这里要额外说一句，很多新人在Windows上装MySQL时，卡在最常见的“MySQL服务启动失败”上。八成原因是3306端口被占用，也可能是缺少VC++运行库。排查方法很简单：执行netstat -ano | findstr 3306看那个进程占用了端口，能停就停。不想折腾的，直接在安装时把端口改成3307，很多本地开发项目的端口就是3307，并不影响学习。

用Docker安装MySQL也是一个很流行的方式，尤其是用来做隔离环境。一条命令就能起一个干净实例：

bash复制docker run -d --name mysql8 -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=root123456 \
  -e TZ=Asia/Shanghai \
  mysql:8.0

每次学习用完了直接把容器删掉重建，不会污染本机环境，非常适合练习和实验。

5.2 完整演示：建库、建表、插入数据、查询分析

假设你已经在命令行里跑通了mysql，下面跟着我做一遍完整流程。先建库：

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

再建三张表：student、course、student_course。表结构就用前面给的模板。建完以后插入几条数据：

sql复制INSERT INTO student (student_name, gender, birth_date, phone) VALUES
('张三', 'M', '2003-05-12', '13800001111'),
('李四', 'F', '2003-08-20', '13800002222'),
('王五', 'M', '2003-02-14', '13800003333'),
('赵六', 'F', '2003-11-30', '13800004444');

INSERT INTO course (course_name, credit) VALUES
('数据库原理', 3),
('操作系统', 4),
('计算机网络', 3),
('算法设计', 4);

INSERT INTO student_course (student_id, course_id, score) VALUES
(1, 1, 92.5),
(1, 2, 88.0),
(1, 3, 76.5),
(2, 2, 90.0),
(2, 4, 83.0),
(3, 1, 65.5),
(3, 4, 79.5),
(4, 3, 95.0);

插入完成后，我们做几个查询练习。查所有学生的姓名和出生日期，按出生日期从早到晚排序：

sql复制SELECT student_name, birth_date FROM student ORDER BY birth_date ASC;

查每个学生的平均分，并按平均分降序排列：

sql复制SELECT s.student_name, AVG(sc.score) AS avg_score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
GROUP BY s.student_id, s.student_name
ORDER BY avg_score DESC;

查选了“数据库原理”这门课的所有学生：

sql复制SELECT s.student_name, sc.score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
JOIN course c ON sc.course_id = c.course_id
WHERE c.course_name = '数据库原理';

这些查询覆盖了JOIN、GROUP BY、聚合函数、ORDER BY，是把CRUD中R的部分吃透的关键练习。

比如查“平均分大于80的学生”，这就是我前面讲过的HAVING场景：

sql复制SELECT s.student_name, AVG(sc.score) AS avg_score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
GROUP BY s.student_id, s.student_name
HAVING AVG(sc.score) >= 80;

跑完这条SQL你会发现，张三的平均分是85.67，李四86.5，赵六95，都被筛出来了。王五的平均分只有72.5，被HAVING挡掉。

我的建议是，把这些SQL挨个用EXPLAIN跑一遍：

sql复制EXPLAIN SELECT s.student_name, AVG(sc.score) AS avg_score
FROM student s
JOIN student_course sc ON s.student_id = sc.student_id
GROUP BY s.student_id, s.student_name
HAVING AVG(sc.score) >= 80;

查看type列和key列，再对照前面讲的执行计划，理解MySQL在每一步做了什么。这个习惯一旦养成，你对SQL的理解会直接从“会写”跳到“会调”。

5.3 用可视化工具辅助学习：Workbench和Navicat怎么选

命令行永远是根，但日常开发和教学里，图形工具确实能提升不少效率。我个人的建议是：学习阶段至少把命令行过一遍，理解每一条SQL的执行逻辑；日常操作则完全可以用图形工具。

MySQL官方自带的Workbench是免费的，功能覆盖建表、查询、导入导出、ER图、Server状态监控，对新手很友好。Workbench界面上方有个“创建ER图”的入口，把三张表拖进去，就能直观看到表和表之间的关联，这一功能对理解JOIN关系非常有帮助。不过Workbench的体积比较大，启动偏慢，偶尔会有字体渲染问题，老机器用起来有些吃力。

Navicat for MySQL是另一款国人用得很多的工具，功能比Workbench更顺手，建表、执行SQL、数据导入导出都做得很完善。它本身是收费的，但网上有许多替代方案，比如DBeaver、HeidiSQL、Sequel Pro（macOS）也都很不错。我的观点是，工具就选自己用着顺手的，不要在“哪个工具更高级”上浪费时间。

可视化工具最大的价值在于，它能帮你“看见”数据。比如在Workbench里执行完一条SELECT，下面会直观显示结果集，这对刚学SQL的人来说，脑子里能迅速建立“条件筛选结果”的映射。但请记住，工具只是表达SQL的窗口，真正决定你水平的还是SQL本身。

6. 高频问题与排查方法：这些坑我基本都踩过

6.1 SQL报错：语法、关键字、和保留字冲突

新手最常见的报错是ERROR 1064 (42000): You have an error in your SQL syntax。这个错误的含义就是“你的SQL语法有错”，但MySQL不会告诉你具体是哪个单词错了，只会给出你出错位置附近的内容。

排错顺序很有讲究。第一，检查引号是否匹配，字符串要用单引号，MySQL默认也接受双引号，但建议统一用单引号。第二，检查关键字是否冲突，比如你建了一张表名叫order，注意order是SQL关键字，建表时会报错。遇到这种情况，要么把表名改成orders，要么给表名加反引号：``` ``order`` ``` `。项目里我通常建议直接换名字，反引号虽然能解决问题，但每次都要记得打，很容易忘。

第三，检查逗号和分号。字段列表里字段之间必须有逗号，但最后一个字段后面不能有逗号。这个错误我在收尾时经常犯。还有，SQL语句要以分号结尾，在命令行里按回车不会执行SQL，必须输入分号再回车。

第四，也是很多人忽略的：确保字段名拼写正确。MySQL报错信息里虽然会提示出错位置，但不会帮你纠错字段名，你只能自己对照表结构去查。比如student_name写成了studnet_name，报错信息早就告诉你了，但你没仔细看。

6.2 查询结果不对：NULL值和空字符串的区别

这是业务里最阴魂不散的一个问题。NULL表示“未定义、未知、不存在”，空字符串表示“我知道这个字段，但它的值是空的”。这两者在数据库里是完全不同的状态。

比如查询用户手机号：

• WHERE phone = ''能查出手机号为空字符串的记录；
• WHERE phone IS NULL能查出手机号未填写的记录；
• 但WHERE phone != ''无法排除NULL记录，因为NULL和空的比较结果是UNKNOWN，那条记录会被直接过滤掉。

所以，如果业务上要求“查所有没填手机号的用户”，你得写：

sql复制SELECT * FROM student WHERE phone IS NULL OR phone = '';

反过来，如果你要排除这两类：

sql复制SELECT * FROM student WHERE phone IS NOT NULL AND phone != '';

写习惯了以后，写过滤条件前先想想：这个字段会不会有NULL？NULL在这个场景下代表什么？想清楚这两个问题，能避开很多隐蔽的BUG。

6.3 深度分页和超时：为什么越到后面的页越慢

很多新人在项目里直接用LIMIT offset, size做分页，数据量小的时候没有任何问题，但等到表数据到百万级，翻到后面几页时，接口延迟会突然飙升到好几秒。

这个问题的根源我之前已经解释过：LIMIT偏移量越大，MySQL需要扫描并丢弃的行数就越多。举个具体例子，LIMIT 900000, 20，MySQL需要扫描900020行，然后只返回最后20行。每行数据都需要读主键索引，开销极大。

优化手段有几种：

• 方案一：应用层记住上一页的最后一条主键，下一页用WHERE id > 上一页最大id ORDER BY id LIMIT 20。这种方式要求排序字段是唯一的，用主键最稳妥。
• 方案二：如果必须用偏移量，可以先用子查询查出偏移位置的ID，再关联回原表获取数据：

sql复制SELECT * FROM student 
WHERE student_id >= (
    SELECT student_id FROM student ORDER BY student_id LIMIT 900000, 1
)
ORDER BY student_id 
LIMIT 20;

• 方案三：业务上不要提供“跳转到第10000页”的功能，只允许上一页和下一页。这是很多面向C端产品的真实选择，深分页的需求本身就不合理。

6.4 连接不上数据库和服务启动失败

连接不上MySQL的报错五花八门，但归结起来无非三类：

第一类，Access denied for user 'root'@'localhost'，用户名或密码错了。检查root密码，或者用root权限重设密码。如果在Docker容器里，检查环境变量里的MYSQL_ROOT_PASSWORD是否设置正确。

第二类，Can't connect to MySQL server on '127.0.0.1' (10061)，说明服务没启动，或者端口不对。Windows下打开服务管理器，确认MySQL服务在运行。Linux下执行systemctl status mysql确认状态。再用telnet 127.0.0.1 3306测试端口是否可通。

第三类，Host 'xxx' is not allowed to connect to this MySQL server。这是远程访问权限问题。默认情况下MySQL只允许localhost访问，如果想让其他机器连接，需要另外创建用户并授权：

sql复制CREATE USER 'dev'@'%' IDENTIFIED BY 'dev123456';
GRANT ALL PRIVILEGES ON school.* TO 'dev'@'%';
FLUSH PRIVILEGES;

注意，'%'表示任意主机，但生产环境千万别用'%'，会带来安全风险。顺带说一下，很多教程会让你改root的host为%，虽然方便，但同样有安全隐患，不建议这么干，自己练习环境随意，项目里坚决不要。

还有一类比较小众的报错：Authentication plugin 'caching_sha2_password' cannot be loaded。MySQL 8.0默认的认证插件是caching_sha2_password，老版本的客户端（比如某些Python库或Navicat旧版）不支持。解决方案有两个：升级客户端；或者把用户的认证插件改回mysql_native_password：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

这个坑在网络上一搜一大把，很多人从MySQL 5.7升级到8.0之后，突然连不上数据库了，八成就是这个原因。

7. 写在“上篇”结尾：CRUD之后，下一步学什么

到这里，“MySQL：CRUD（上）”就告一段落了。这一篇里，我带着你把Create和Read的相关环节捋了一遍：建库建表时字段类型和字符集的选择、INSERT三种写法和主键冲突的处理、SELECT在过滤、排序、聚合、多表关联上的常见写法和底层逻辑，以及索引和EXPLAIN这些查询性能相关的核心知识。

我在实际带新人的过程中发现，能把CRUD写对的人不少，但能在CRUD的基础上解释清楚“为什么这样设计”的人很少。比如问你：为什么要用自增主键？为什么字符集要用utf8mb4？为什么GROUP BY里要带上所有非聚合字段？为什么INNER JOIN和LEFT JOIN结果不一样？这些问题背后，才是MySQL真正值得花时间的地方。CRUD只是入口，不是终点。

接下来建议你打开命令行或者图形工具，把建表和查询练习亲手跑一遍，然后试着往表里插入几万条数据，用EXPLAIN看看全表扫描和走索引的差别。等到上篇的内容都熟练了，就可以开始看“MySQL：CRUD（下）”，也就是UPDATE和DELETE相关的深入内容：事务隔离级别在修改数据时怎么影响结果，行锁和表锁在什么场景下会出现，批量更新怎么做安全，删除数据的时候为什么不能直接DELETE FROM。这些坑，下一篇里我们一个一个拆。

我自己当初学MySQL时，最犯怵的就是“只看不练”。后来有个前辈跟我说了一句话：SQL这东西，眼睛会了不算会，手会了才算。你在终端里敲一遍，和只在教程里看一遍，完全是两回事。所以，赶紧去建一张自己的表，造几条假数据，动手跑一遍再说吧。