简介：本资源为《MySQL数据库应用与开发》教材配套实训报告，面向高校计算机相关专业学生及MySQL初学者，帮助读者在Windows10环境下通过MySQL 5.7完成从安装到数据库管理的完整实操训练。报告围绕姜桂洪主编、清华大学出版社2018年版教材前六章案例整理而成，涵盖安装MySQL服务器、数据库基本操作、表及数据完整性、数据检索、索引和视图五大模块，实验步骤均经手动实践验证可行。资源包共1个doc文件，大小约6.61MB，内容以图文结合方式呈现建库建表、字符集修改、主键外键约束、select单表与多表查询等具体操作过程。目前已有2475人学习下载，适合需要对照教材完成课程实训、巩固SQL语句书写与数据库设计思路的读者参考使用。
1. 实训报告不是流水账：从建库到事务，一份能跑通的 MySQL 交付物长什么样
很多人拿到「MySQL数据库应用与开发实训报告」这个题目，第一反应是去搜模板，然后把安装截图、建表语句、几条增删改查命令拼在一起交差。但真正做过企业级交付的工程师都知道，一份有价值的实训报告，本质是一条可复现的技术链路：从环境搭建、库表设计、数据操作，到事务控制和性能观察，每一步都要有据可查、有错可排。它解决的不是「证明我装过 MySQL」，而是「证明我能用 MySQL 把一套业务数据管起来」。适合谁看？刚学完 SQL 语法但没独立建过库的在校生，以及需要带新人做数据库实训的技术负责人。接下来我按实际交付顺序，把这份报告拆成能直接抄作业的六个环节，中间会穿插 mysql 安装配置教程、数据库增删改查、mysql 事务处理这些高频搜索点里真正容易翻车的地方。
2. 环境落地：MySQL 8.0 在 Windows 与 Linux 上的最小可用配置
2.1 版本选择与安装方式：为什么我不建议新手直接上 Docker
热词里 mysql 安装教程 8.0、mysql 5.7.44 安装过程详细、docker 安装 mysql 失败 出现频率极高，说明环境这一步卡住了大量人。我的建议很直接：实训报告要求的是「可验证的数据库行为」，不是容器编排能力。Windows 10 上就用官方 MSI 安装包，Linux 上用 rpm 或 tar.gz 解压配置，先把服务跑起来、能连上、能建库，再考虑容器化。
Windows 下安装 MySQL 8.0 的关键不是一路点 Next，而是这三个决策点：第一，Choosing a Setup Type 选 Custom，只装 Server 和 MySQL Workbench，避免装一堆用不上的组件；第二，Authentication Method 选 Use Strong Password Encryption，但如果你后续要用老版本客户端连接，改成 Legacy Authentication；第三，Windows Service 勾选 Configure MySQL Server as a Windows Service，服务名保持默认 MySQL80，这样开机自启，不用每次手动 net start。
Linux 下如果用 rpm 安装，顺序不能错，依赖关系会导致安装失败：
# 按顺序安装，common 和 libs 必须先于 client 和 server rpm -ivh mysql-community-common-8.0.xx.rpm rpm -ivh mysql-community-client-plugins-8.0.xx.rpm rpm -ivh mysql-community-libs-8.0.xx.rpm rpm -ivh mysql-community-client-8.0.xx.rpm rpm -ivh mysql-community-icu-data-files-8.0.xx.rpm rpm -ivh mysql-community-server-8.0.xx.rpm # 启动并获取初始临时密码 systemctl start mysqld grep 'temporary password' /var/log/mysqld.log逻辑说明：common 包提供错误信息和字符集，libs 提供客户端库，client-plugins 提供认证插件，icu-data-files 提供国际化支持，server 包依赖前面所有包。如果跳过中间任何一个，rpm 会报依赖错误，这时候不要用 --nodeps 强行安装，否则服务启动时会报 lib 缺失。
参数说明：安装完成后必须执行 mysql_secure_installation，它会引导你改 root 密码、移除匿名用户、禁止 root 远程登录、删除 test 库。实训环境里我一般保留 root 本地登录，但会创建一个专用实训账号，避免用 root 做增删改查。
提示：docker 安装 mysql 失败 最常见的原因是端口映射写成了 3306:3306 但宿主机 3306 已被占用，或者挂载的 data 目录权限不对导致容器反复重启。如果非要用 Docker，先 docker logs 看报错，再决定是改端口还是改挂载路径。
2.2 连接与字符集：实训报告里最容易被忽略的两个配置
装完能连上只是第一步。实训报告要记录连接方式，我一般要求同时写命令行连接和客户端工具连接两种。命令行用 mysql -u 用户名 -p -h 主机地址 -P 端口，客户端工具可以用 MySQL Workbench 或 dbx 数据库工具，后者在热词里出现多次，它的优势是轻量、支持多数据库切换，适合同时管 MySQL 和 sqllite 数据库 的场景。
字符集配置是实训报告里区分「随便做做」和「认真做过」的分水岭。MySQL 8.0 默认字符集已经是 utf8mb4，但如果你从 5.7 升级或者用旧配置文件，可能还是 latin1。建库前先确认：
-- 查看当前字符集相关变量 SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%'; -- 建库时显式指定，不要依赖默认值 CREATE DATABASE training_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci;逻辑说明：character_set_server 决定服务器默认字符集，character_set_database 决定当前库默认字符集。如果建库时不指定，会继承服务器设置。utf8mb4 和 utf8 的区别在于前者支持 4 字节字符（比如 emoji 和部分生僻字），实训报告里如果涉及用户昵称、评论内容，必须用 utf8mb4，否则插入特殊字符会报 Incorrect string value 错误。
参数说明：utf8mb4_0900_ai_ci 是 MySQL 8.0 默认排序规则，ai 表示 accent insensitive（不区分重音），ci 表示 case insensitive（不区分大小写）。如果你的业务需要区分大小写，改成 utf8mb4_0900_as_cs。实训报告里写清楚选哪个、为什么选，比只贴一条建库语句有说服力得多。
3. 库表设计与增删改查：把业务需求翻译成 SQL 的完整过程
3.1 从 ER 图到建表语句：字段类型和约束怎么定
实训报告通常会给一个业务场景，比如学生选课、图书管理、订单系统。不管哪个场景，建表前先画 ER 图，确定实体、属性和关系，然后逐字段确定类型。这一步的常见错误是字段类型选得过大或过小：用 VARCHAR(255) 存手机号、用 INT 存金额、用 DATETIME 但不设默认值。
我一般按这个原则定类型：整数用 INT 或 BIGINT，金额用 DECIMAL(10,2)，短文本用 VARCHAR(50) 到 VARCHAR(255)，长文本用 TEXT，时间用 DATETIME 并设 DEFAULT CURRENT_TIMESTAMP。主键统一用 BIGINT UNSIGNED AUTO_INCREMENT，外键字段类型必须和主键完全一致，包括 UNSIGNED。
以学生选课为例，三张表的建表语句：
-- 学生表 CREATE TABLE student ( student_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT NOT NULL DEFAULT 0 COMMENT '0未知 1男 2女', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (student_id), UNIQUE KEY uk_student_no (student_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 课程表 CREATE TABLE course ( course_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, credit DECIMAL(3,1) NOT NULL DEFAULT 0.0, PRIMARY KEY (course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 选课关联表 CREATE TABLE student_course ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, student_id BIGINT UNSIGNED NOT NULL, course_id BIGINT UNSIGNED NOT NULL, score DECIMAL(5,2) DEFAULT NULL, selected_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_student_course (student_id, course_id), KEY idx_course_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;逻辑说明：student_course 表用联合唯一索引 uk_student_course 防止同一学生重复选同一门课，这是业务约束落到数据库层面的典型做法。外键约束保证选课记录不会引用不存在的学生或课程。idx_course_id 索引用于加速「按课程查选课名单」的查询。
参数说明：ENGINE=InnoDB 是必须的，因为只有 InnoDB 支持事务和外键。DECIMAL(3,1) 表示总共 3 位、小数 1 位，最大 99.9，够存学分。DECIMAL(5,2) 最大 999.99，够存百分制成绩。TINYINT 存性别比 VARCHAR 省空间且查询快。
3.2 增删改查的实训写法：不要只写 SELECT *
数据库增删改查 是热词里最核心的操作，但实训报告里如果只写 INSERT INTO ... VALUES、SELECT * FROM ...，看不出水平。我要求按「单条插入、批量插入、条件查询、聚合查询、更新、删除」六个维度各写至少一条，并且每条都要有业务含义。
-- 单条插入 INSERT INTO student (student_no, student_name, gender) VALUES ('2024001', '张三', 1); -- 批量插入，一条语句插多行，减少网络往返 INSERT INTO student (student_no, student_name, gender) VALUES ('2024002', '李四', 2), ('2024003', '王五', 1), ('2024004', '赵六', 2); -- 条件查询：查性别为男且学号大于 2024001 的学生 SELECT student_id, student_no, student_name FROM student WHERE gender = 1 AND student_no > '2024001' ORDER BY student_no ASC; -- 聚合查询：统计每个性别的学生人数 SELECT gender, COUNT(*) AS cnt FROM student GROUP BY gender HAVING cnt > 0; -- 更新：给指定学生改姓名 UPDATE student SET student_name = '张三丰' WHERE student_no = '2024001'; -- 删除：删除没有选课记录的学生（注意外键约束） DELETE FROM student WHERE student_id NOT IN (SELECT DISTINCT student_id FROM student_course);逻辑说明：批量插入比循环单条插入快一个数量级，因为减少了客户端与服务器之间的通信次数。聚合查询里 GROUP BY 后面跟 HAVING 而不是 WHERE，因为 WHERE 过滤的是行，HAVING 过滤的是分组结果。删除语句里用 NOT IN 子查询先找出没有选课的学生，避免直接删有外键关联的记录导致报错。
参数说明：ORDER BY student_no ASC 里的 ASC 可以省略，默认就是升序。COUNT(*) 统计所有行，COUNT(字段) 会跳过 NULL 值，实训报告里要写清楚用哪个、为什么。UPDATE 和 DELETE 必须带 WHERE，否则全表更新或删除，这是血泪经验，实训环境里我一般先 SELECT 确认条件再执行。
注意：mysql 设置默认值为 0 这类操作，如果字段允许 NULL 且没有默认值，插入时省略该字段会存 NULL 而不是 0。建表时用 NOT NULL DEFAULT 0 明确约束，比事后用 UPDATE 补数据可靠。
4. 事务与锁：实训报告里最能体现工程思维的部分
4.1 事务的 ACID 怎么在 MySQL 里验证
mysql 事务处理 是热词里技术含量最高的一个。实训报告如果只写「事务有 ACID 四个特性」，那是背书，不是实训。我要求用两条会话窗口实际演示：开启事务、执行更新、另一会话查询、提交或回滚、再查询，把中间状态截图记录。
-- 会话 A START TRANSACTION; UPDATE student_course SET score = 95.00 WHERE student_id = 1 AND course_id = 1; -- 此时不提交，会话 B 查询该记录 -- 会话 B SELECT score FROM student_course WHERE student_id = 1 AND course_id = 1; -- 在 REPEATABLE READ 隔离级别下，会话 B 看到的是旧值 -- 会话 A COMMIT; -- 会话 B 再次查询，看到新值 95.00逻辑说明：MySQL InnoDB 默认隔离级别是 REPEATABLE READ。会话 A 更新但未提交时，会话 B 在同一个事务里多次读会看到一致快照，这就是可重复读。只有 A 提交后，B 开启新事务才能看到新值。这个实验能直观验证隔离级别的存在，比背概念强得多。
参数说明：START TRANSACTION 和 BEGIN 等价。COMMIT 提交事务，ROLLBACK 回滚事务。如果会话 A 执行更新后不提交也不回滚，直接断开连接，MySQL 会自动回滚未提交事务。实训报告里要记录 autocommit 变量的值，默认是 ON，意味着每条 SQL 都是一个独立事务。
4.2 锁的分类与死锁排查：数据库并发锁 的实训观察
mysql 锁的分类 和 数据库死锁 是热词里偏进阶的内容，实训报告里如果能加上锁的观察实验，档次会明显提升。InnoDB 的锁按粒度分表锁和行锁，按模式分共享锁（S 锁）和排他锁（X 锁）。普通 SELECT 不加锁，SELECT ... FOR UPDATE 加 X 锁，SELECT ... LOCK IN SHARE MODE 加 S 锁。
死锁实验这样设计：两个会话各自持有不同行的锁，然后互相请求对方持有的锁。
-- 会话 A START TRANSACTION; UPDATE student SET student_name = 'A' WHERE student_id = 1; -- 不提交 -- 会话 B START TRANSACTION; UPDATE student SET student_name = 'B' WHERE student_id = 2; -- 不提交 -- 会话 A 请求 student_id = 2 的锁 UPDATE student SET student_name = 'A2' WHERE student_id = 2; -- 阻塞 -- 会话 B 请求 student_id = 1 的锁 UPDATE student SET student_name = 'B2' WHERE student_id = 1; -- 死锁触发，MySQL 自动回滚其中一个事务逻辑说明：InnoDB 有死锁检测机制，当检测到循环等待时会自动回滚代价较小的事务，并报 ERROR 1213: Deadlock found when trying to get lock。实训报告里要记录这个报错，并用 SHOW ENGINE INNODB STATUS 查看死锁详情。
参数说明：innodb_lock_wait_timeout 控制锁等待超时时间，默认 50 秒。如果业务里锁等待频繁，可以适当调小，让失败快速暴露而不是长时间阻塞。innodb_deadlock_detect 默认 ON，生产环境一般保持开启，除非死锁检测本身成为性能瓶颈。
提示：实训报告里写死锁实验，一定要在测试库做，不要在生产库或共享库做。我见过有人在实训环境里锁了核心表，导致整个小组的作业提交不上，这就是没有隔离环境的教训。
5. 避坑与排查：实训报告里必须记录的 5 个真实翻车现场
5.1 现象：安装后服务启动失败，日志报「The server quit without updating PID file」
原因：数据目录权限不对，或者 my.cnf 里配置了不存在的路径。Linux 下 rpm 安装后数据目录默认是 /var/lib/mysql，如果手动改过 datadir 但没改权限，mysqld 进程无法写入。
解决：先看 /var/log/mysqld.log 最后 50 行，确认具体报错路径。然后 chown -R mysql:mysql /var/lib/mysql，再 systemctl start mysqld。如果是自定义 datadir，确保 my.cnf 里 datadir 和实际路径一致，且 mysql 用户有读写权限。
5.2 现象：插入中文报「Incorrect string value: '\xE5\xBC\xA0...' for column」
原因：表或字段字符集不是 utf8mb4，或者客户端连接字符集不是 utf8mb4。常见于从旧版本迁移或手动建表时没指定字符集。
解决：先 SHOW CREATE TABLE 表名 确认表字符集，再 SHOW VARIABLES LIKE 'character_set_client' 确认连接字符集。建表时显式写 DEFAULT CHARSET=utf8mb4，连接时执行 SET NAMES utf8mb4。如果表已经建好，用 ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4 修改。
5.3 现象：DELETE 或 UPDATE 影响行数为 0，但数据明明存在
原因：WHERE 条件里的字段类型和值类型不匹配，导致隐式转换后比较失败。比如字段是 VARCHAR 但用数字比较，或者字段有空格而查询值没有。
解决：用 SELECT 先验证 WHERE 条件能查出数据，再执行 UPDATE 或 DELETE。检查字段类型和值类型是否一致，字符串比较注意前后空格，必要时用 TRIM 函数。开启 safe updates 模式时，UPDATE 和 DELETE 必须带主键或索引条件，否则报错 1175。
5.4 现象：事务里更新了数据，另一个会话查不到，以为事务没生效
原因：MySQL 默认隔离级别 REPEATABLE READ，未提交事务的修改对其他会话不可见。另一个会话如果也在事务中，看到的是事务开始时的快照。
解决：确认第一个会话是否执行了 COMMIT。如果确实需要跨会话看到未提交数据，把隔离级别改成 READ UNCOMMITTED，但生产环境不推荐。实训报告里把这个现象记录下来，正好说明隔离级别的实际效果。
5.5 现象：mysql ssl 连接错误，客户端报「SSL connection error: unknown error number」
原因：MySQL 8.0 默认启用 SSL，但客户端版本较旧或证书配置不匹配。常见于用老版本 Navicat 或命令行客户端连接 8.0 服务器。
解决：在连接字符串里加 useSSL=false 或 ssl-mode=DISABLED。命令行连接用 mysql --ssl-mode=DISABLED -u 用户 -p。如果必须用 SSL，确认服务器端证书路径和客户端信任配置一致。实训环境里如果只是本地练习，关闭 SSL 不影响功能验证。
6. 从实训到实战：把报告里的 SQL 变成可复用的脚本资产
一份实训报告如果只交 Word 文档，价值有限。我习惯把报告里的所有 SQL 整理成三个脚本文件：schema.sql 存建库建表语句，data.sql 存初始化数据，queries.sql 存所有查询和事务实验。这样下次换一个业务场景，改 schema 和 data 就能复用整套查询逻辑。
更进一步，把常用操作封装成存储过程，减少重复 SQL。比如「按学号查选课和成绩」这个查询，实训报告里可能写了三遍，封装成存储过程后调用一次即可：
DELIMITER // CREATE PROCEDURE get_student_courses(IN p_student_no VARCHAR(20)) BEGIN SELECT s.student_no, 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_no = p_student_no ORDER BY c.course_name; END // DELIMITER ; -- 调用 CALL get_student_courses('2024001');逻辑说明：DELIMITER 临时把语句结束符从分号改成 //，因为存储过程内部有分号，不改的话 MySQL 会在第一个分号处截断。存储过程创建后存在数据库里，调用时只传参数，不用重复写 JOIN。实训报告里加上这个，能体现「从写 SQL 到设计接口」的思维转变。
参数说明：IN 表示入参，还有 OUT 和 INOUT。p_student_no 的类型要和 student 表里 student_no 字段类型一致，否则可能走不了索引。存储过程适合逻辑固定、调用频繁的场景，如果业务变化快，用视图或应用层拼 SQL 更灵活。
验证方法：建完存储过程后，用 SHOW PROCEDURE STATUS WHERE Db = 'training_db' 查看是否存在，用 CALL 调用看结果是否正确，再用 DROP PROCEDURE IF EXISTS 测试删除重建。实训报告里记录这套验证流程，比只贴创建语句完整得多。
我自己的习惯是，每做完一个实训模块，就把对应的 SQL 脚本提交到版本控制里，注释写清楚业务含义和参数说明。几年下来，这些脚本就是最实在的资产，换数据库版本、换业务场景，改改就能用。希望帮到你。
本文还有配套的精品资源，点击获取
