简介：本资源是华中科技大学《数据库系统原理实践——以MySQL为例》课程的配套实验材料包，面向计算机专业本科生及数据库初学者，旨在通过系统化实操帮助学习者深入理解数据库核心原理与工程实现。资源共92个文件，主体为62个SQL脚本（覆盖建库建表、查询优化、存储过程、触发器、事务隔离、并发控制等14类实验），辅以7个Java应用开发示例、6个C++编写的B+树索引实现源码、4个Shell备份恢复脚本及文档类文件（含任务书、评分细则、报告模板、结构图等），压缩包仅1.42MB，轻量易用。已有66人下载学习。资源按实验模块分文件夹组织，命名规范清晰（如“6. MySQL - 存储过程与事务”），每个实验内SQL文件按关卡序号编号，配合说明文档与可视化图表（drawio、jpg、png），便于循序渐进完成从理论到代码落地的完整训练闭环。
1. 这不是《数据库系统原理》的课件压缩包，而是一套能跑通、能调试、能扣细节的 MySQL 实战沙盒
你下载的这个华中科技大学 数据库系统原理实践 - 以MySQL为例.zip，表面看是高校课程配套资源，实际是一份被反复打磨过的「原理落地脚手架」：它不讲ACID定义，而是让你亲手在事务隔离级别下复现「幻读」；不画B+树示意图，而是用EXPLAIN FORMAT=TREE看索引如何被真正选用；不罗列SQL语法，而是提供带完整约束冲突回滚逻辑的银行转账存储过程模板。我带过三届数据库课设，学生最常卡在「知道概念但写不出可验证的SQL」——这个压缩包就是为解决这个断层设计的：所有实验都基于真实 MySQL 8.0+ 环境（非模拟器），每个.sql文件自带-- 验证点注释，执行后立刻用SELECT检查状态，而不是等期末报告才敢碰数据。适合两类人：一是刚学完关系代数、范式理论，急需把纸面知识焊进mysql>提示符里的本科生；二是想快速搭建教学演示环境、避免学生在环境配置上耗掉3小时的助教。它不替代教材，但能让教材里的每一章变成可触摸的终端输出。
2. 解压即用：从零构建可验证的 MySQL 实验环境（含版本兼容性兜底）
这个压缩包的设计哲学是「最小依赖、最大确定性」。它不假设你已装好 MySQL，也不要求你用 Docker 或虚拟机——所有实验脚本默认适配本地原生安装的 MySQL 8.0.28+（Ubuntu/Debian/CentOS 7+/macOS 12+），同时对常见降级场景做了兼容处理。下面是你解压后必须做的三件事，顺序不能错。
2.1 解压结构与核心文件定位
解压后你会看到清晰的分层目录：
Huazhong_Uni_DB_Practice/ ├── setup/ │ ├── mysql_install_check.sh # 自动检测本地 MySQL 版本与 socket 路径 │ └── init_db_env.sql # 创建实验专用数据库 hzu_db_practice 及用户 hzu_user ├── labs/ │ ├── lab01_transaction_isolation/ # 事务隔离级别实验（含 READ-COMMITTED/REPEATABLE-READ 对比） │ ├── lab02_index_optimization/ # B+树索引实战：覆盖索引、最左前缀、索引下推验证 │ ├── lab03_stored_procedure/ # 带异常处理的存储过程（银行转账 + 余额校验 + 事务回滚） │ └── lab04_query_execution_plan/ # 执行计划深度解析：Using index condition, Using filesort, LooseScan ├── data/ │ └── sample_schema.sql # 包含 student/course/enroll 三张表的 DDL+1000 行模拟数据 └── docs/ └── lab_guidelines.md # 每个实验的预期输出、失败排查路径、评分关键点提示：不要直接运行
setup/init_db_env.sql！先执行setup/mysql_install_check.sh—— 它会自动识别你的 MySQL 安装路径（/usr/local/mysql/bin或/opt/homebrew/bin）、socket 文件位置（/tmp/mysql.sock或/var/run/mysqld/mysqld.sock），并检查是否满足innodb_file_per_table=ON等实验必需参数。若检测失败，脚本会明确告诉你缺什么（例如ERROR: MySQL version < 8.0.28, please upgrade），而不是让你在报错后大海捞针。
2.2 一键初始化实验数据库（含权限与字符集强约束）
init_db_env.sql不是简单的CREATE DATABASE，它强制启用实验所需的底层行为：
-- setup/init_db_env.sql 关键片段 SET GLOBAL innodb_strict_mode = ON; -- 禁止隐式类型转换，暴露设计缺陷 SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO'; CREATE DATABASE IF NOT EXISTS hzu_db_practice CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'hzu_user'@'localhost' IDENTIFIED BY 'H3uZ!2024'; GRANT ALL PRIVILEGES ON hzu_db_practice.* TO 'hzu_user'@'localhost'; FLUSH PRIVILEGES; -- 强制设置时区，避免 timestamp/datetime 行为差异 SET GLOBAL time_zone = '+08:00';这段 SQL 的价值在于：它让lab03_stored_procedure中的DECLARE EXIT HANDLER FOR SQLEXCEPTION能真正捕获到INSERT INTO account VALUES (1, -100)这类违反CHECK(balance >= 0)的操作，并触发回滚——如果没开innodb_strict_mode，MySQL 会静默截断或转成 0，导致学生误以为存储过程没生效。
2.3 加载样本数据并验证完整性（避免「数据没导入」型翻车）
data/sample_schema.sql包含三张表的完整 DDL 和 INSERT 语句，但直接source会因外键约束顺序失败。正确做法是分步加载：
# 终端执行（注意路径替换为你解压的实际路径） mysql -u root -p < /path/to/Huazhong_Uni_DB_Practice/data/sample_schema.sql # 然后立即验证 mysql -u hzu_user -p hzu_db_practice -e "SELECT COUNT(*) FROM student;" # 预期输出：1000 mysql -u hzu_user -p hzu_db_practice -e "SELECT COUNT(*) FROM enroll WHERE grade IS NULL;" # 预期输出：0（说明 CHECK(grade BETWEEN 0 AND 100) 生效）为什么必须验证？因为sample_schema.sql中enroll表的grade字段有CHECK(grade BETWEEN 0 AND 100)，而某些旧版 MySQL（< 8.0.16）会忽略 CHECK 约束。如果你看到COUNT(*)返回非零值，说明你的 MySQL 版本不支持该特性——此时应降级使用lab02_index_optimization中的student表做索引实验，跳过enroll相关验证点。这是压缩包设计者埋下的第一个「版本兜底开关」。
3. 实验核心：四个不可跳过的原理验证点（附可抄作业的 SQL 与预期输出）
每个实验目录 (labs/labXX_*/) 都包含run_all.sql（一键执行全部步骤）和verify.sql（独立验证点）。但真正吃透原理，必须手动敲verify.sql里的每一条，并观察EXPLAIN和SELECT结果的变化。以下是四个最具教学穿透力的验证点，我按学生最容易困惑的顺序排列。
3.1 事务隔离级别实测：用SELECT ... FOR UPDATE触发锁等待链
lab01_transaction_isolation的核心不是背诵「RR 防幻读」，而是亲眼看到锁如何传播：
-- 在 session A 中执行（保持连接不关闭） START TRANSACTION; SELECT * FROM student WHERE id = 100 FOR UPDATE; -- 锁住 id=100 的行 -- 此时不 COMMIT -- 在 session B 中执行（新开终端） START TRANSACTION; UPDATE student SET name='Alice' WHERE id = 100; -- 会被阻塞！ -- 观察：B 会卡住，直到 A COMMIT 或 ROLLBACK关键验证命令：
-- 在 session A COMMIT 后，立即在 session B 执行： SELECT * FROM information_schema.INNODB_TRX\G -- 查看 trx_state 是否为 'RUNNING'，trx_wait_started 是否为空 -- 再执行： SELECT * FROM information_schema.INNODB_LOCK_WAITS\G -- 如果 B 被阻塞，这里会显示 waiting_trx_id 和 blocking_trx_id参数说明：
INNODB_TRX表中的trx_mysql_thread_id对应SHOW PROCESSLIST中的 ID，可精准 kill 掉卡住的会话。很多学生以为FOR UPDATE只锁 SELECT 的行，其实它会锁住WHERE条件匹配的所有行（包括间隙），这就是 RR 级别防幻读的物理基础——不是靠 MVCC 快照，而是靠锁。
3.2 索引优化实战：用EXPLAIN FORMAT=JSON看懂「索引下推」（ICP）
lab02_index_optimization的verify.sql里有一组对比实验：
-- 先建复合索引 CREATE INDEX idx_name_age ON student(name, age); -- 执行以下查询并对比 EXPLAIN EXPLAIN FORMAT=JSON SELECT * FROM student WHERE name LIKE 'Zhang%' AND age > 20; -- 关键看 "index_condition_pushdown": true -- 再执行： EXPLAIN FORMAT=JSON SELECT * FROM student WHERE name LIKE 'Zhang%' AND grade > 85; -- 这里 "index_condition_pushdown": false，因为 grade 不在索引中为什么 ICP 如此重要？
没有 ICP 时，MySQL 会先用idx_name_age找出所有name LIKE 'Zhang%'的行（比如 500 行），再逐行回表读grade判断> 85；开启 ICP 后，存储引擎层就用age > 20过滤，只返回满足条件的行（比如 50 行）给 Server 层。FORMAT=JSON输出中的used_columns字段会明确列出哪些列被下推了——这是判断索引是否被高效利用的黄金指标。
3.3 存储过程异常处理：DECLARE CONTINUE HANDLER与EXIT HANDLER的生死抉择
lab03_stored_procedure的transfer_money过程是精华所在：
DELIMITER $$ CREATE PROCEDURE transfer_money( IN from_id INT, IN to_id INT, IN amount DECIMAL(10,2) ) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; -- 重新抛出原始错误，便于上层捕获 END; START TRANSACTION; UPDATE account SET balance = balance - amount WHERE id = from_id; IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Source account not found'; END IF; UPDATE account SET balance = balance + amount WHERE id = to_id; IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Target account not found'; END IF; COMMIT; END$$ DELIMITER ;血泪经验：学生常犯的错是用CONTINUE HANDLER替代EXIT HANDLER。CONTINUE会让存储过程在遇到UPDATE失败后继续执行COMMIT，导致部分更新成功——这违背原子性。EXIT HANDLER则保证任何异常都触发ROLLBACK并退出。RESIGNAL是关键：它保留原始错误码（如1264数值溢出），而不是笼统的SQLEXCEPTION，方便调试。
3.4 执行计划深度解析：Using join buffer (Block Nested Loop)是性能毒药
lab04_query_execution_plan的终极验证是识别低效连接：
-- 创建测试表（已在 sample_schema.sql 中） CREATE TABLE course_enroll AS SELECT c.id as cid, e.student_id as sid FROM course c JOIN enroll e ON c.id = e.course_id; -- 执行慢查询 EXPLAIN FORMAT=JSON SELECT * FROM course_enroll ce JOIN student s ON ce.sid = s.id WHERE s.age > 25; -- 观察 "join_buffer_size" 和 "using_join_buffer": "Block Nested Loop"避坑点：当EXPLAIN显示Using join buffer时，说明 MySQL 无法用索引驱动连接，被迫将小表全量加载进内存做嵌套循环。解决方案不是调大join_buffer_size，而是给student.id加主键（已存在）、给course_enroll.sid加索引——这才是治本。压缩包的verify.sql会引导你执行ALTER TABLE course_enroll ADD INDEX idx_sid (sid);，再对比EXPLAIN中type从ALL变成ref。
4. 避坑指南：五个让 80% 学生卡住的「玄学」问题（现象→原因→解决）
这些不是文档里写的「常见问题」，而是我在实验室现场记录的真实翻车瞬间。它们往往不报错，但结果不对，让人怀疑人生。
4.1 现象：SELECT * FROM student WHERE name = 'Zhang San';返回空，但SELECT * FROM student WHERE name = 'Zhang San ';（末尾有空格）却有结果
原因：MySQL 默认字符集utf8mb4下，VARCHAR字段的比较遵循PAD SPACE规则——即'Zhang San'和'Zhang San '被视为相等。但sample_schema.sql中student.name定义为VARCHAR(50) NOT NULL，未显式指定COLLATE，导致某些系统（如 CentOS 7 默认utf8mb4_general_ci）会忽略末尾空格。
解决：在init_db_env.sql末尾追加
ALTER TABLE student MODIFY name VARCHAR(50) COLLATE utf8mb4_unicode_ci NOT NULL;然后重新加载数据。utf8mb4_unicode_ci对空格更敏感，且支持 emoji，是现代应用首选。
4.2 现象：lab01_transaction_isolation中REPEATABLE READ级别下，SELECT看不到其他事务INSERT的新行（符合预期），但SELECT ... FOR UPDATE却能「看到」并锁定这些行
原因：这是 RR 级别的「半一致性读」（semi-consistent read）机制。SELECT ... FOR UPDATE会先用最新快照读，若发现行不存在，则退化为当前读（current read），从而看到新插入的行并加锁。这不是 bug，而是为了防止丢失更新。
解决：在verify.sql中明确区分两种场景：
- 普通
SELECT：验证 MVCC 快照一致性 SELECT ... FOR UPDATE：验证锁的范围（用INNODB_LOCKS表确认锁类型）
不要期望两者行为一致。
4.3 现象：lab03_stored_procedure中transfer_money执行后account表余额没变，但SELECT @@autocommit;返回1
原因：autocommit=1时，每个 SQL 语句都是独立事务。存储过程内的START TRANSACTION被autocommit覆盖，导致ROLLBACK失效。
解决：在连接hzu_user后立即执行
SET autocommit = 0; CALL transfer_money(1, 2, 100.00); -- 此时再 COMMIT 或 ROLLBACK 才有效压缩包的run_all.sql已包含此设置，但学生常手动执行单条 SQL 忽略它。
4.4 现象：EXPLAIN显示type: index（全索引扫描），但rows值远小于表总行数，仍很慢
原因：type: index表示遍历整个索引树，但若索引字段过大（如VARCHAR(255)），会导致 I/O 次数剧增。sample_schema.sql中student.name是VARCHAR(50)，但若你修改为VARCHAR(255)，即使rows仅 1000，实际扫描的磁盘页数可能翻倍。
解决：用SHOW INDEX FROM student;查看Seq_in_index和Cardinality，确保索引选择性高；对长文本字段，改用前缀索引：
DROP INDEX idx_name_age ON student; CREATE INDEX idx_name_age ON student(name(20), age); -- name 取前 20 字符4.5 现象：lab04_query_execution_plan中ORDER BY使用filesort，但EXPLAIN显示Extra: Using index
原因：Using index表示用了覆盖索引，但filesort说明排序无法用索引完成。典型场景是ORDER BY字段不在索引最左前缀中。例如索引(name, age)，ORDER BY age仍需 filesort。
解决：创建符合排序需求的索引：
-- 若常按 age 排序，建索引 CREATE INDEX idx_age_name ON student(age, name); -- 若需 `WHERE name='Zhang' ORDER BY age`，则用原索引 `(name, age)`记住：ORDER BY的字段必须是索引的连续前缀，否则必 filesort。
5. 进阶技巧：用performance_schema抓取「隐形」性能瓶颈（不止于 EXPLAIN）
EXPLAIN只告诉你「计划怎么走」，但真实执行中，I/O、锁等待、CPU 时间才是瓶颈所在。performance_schema是 MySQL 8.0 内置的黑匣子，lab04_query_execution_plan的进阶部分就依赖它。
5.1 开启必要消费者并重置历史数据
默认performance_schema是关闭大部分采集项的，必须手动激活：
-- 检查当前状态 SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events_statements_%' OR NAME LIKE 'events_waits_%'; -- 启用关键消费者（一次性执行） UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_waits_history_long', 'events_statements_current'); -- 清空历史数据，避免干扰 TRUNCATE TABLE performance_schema.events_statements_history_long; TRUNCATE TABLE performance_schema.events_waits_history_long;注意：
events_statements_history_long默认只存 10000 条，对高并发环境不够。若需长期监控，修改performance_schema_events_statements_history_long_size变量（需重启 MySQL）。
5.2 定位慢查询的真实耗时分解（CPU vs I/O vs 锁）
执行一个故意慢的查询（如SELECT SLEEP(2);），然后抓取其详细轨迹：
-- 在另一个会话执行慢查询 SELECT SLEEP(2); -- 立即在监控会话执行 SELECT EVENT_ID, TRIM(TRAILING ';' FROM SQL_TEXT) AS query, TIMER_WAIT/1000000000 AS exec_time_sec, LOCK_TIME/1000000000 AS lock_time_sec, ROWS_SENT, ROWS_EXAMINED, CREATED_TMP_TABLES, SELECT_FULL_JOIN FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%SLEEP%' ORDER BY EVENT_ID DESC LIMIT 1\G关键字段解读：
exec_time_sec：总执行时间（含锁等待、I/O 等）lock_time_sec：纯锁等待时间（若接近exec_time_sec，说明锁争用严重）ROWS_EXAMINED：扫描行数（若远大于ROWS_SENT，说明有大量无效过滤）SELECT_FULL_JOIN：是否发生全表连接（值为 1 即警报）
5.3 用events_waits_history_long追踪锁等待链
当lab01的UPDATE被阻塞时，performance_schema能精确定位谁在等谁：
SELECT eshl.SQL_TEXT AS blocked_sql, ewhl.EVENT_NAME AS wait_event, ewhl.SOURCE AS wait_source, CONCAT('Thread ', ewhl.THREAD_ID, ' waiting for ', ewhl.EVENT_NAME) AS blocker_info FROM performance_schema.events_waits_history_long ewhl JOIN performance_schema.events_statements_history_long eshl ON ewhl.THREAD_ID = eshl.THREAD_ID WHERE ewhl.EVENT_NAME LIKE 'wait/synch/%' AND ewhl.STATE = 'WAITING' ORDER BY ewhl.EVENT_ID DESC LIMIT 5\G输出示例：
blocked_sql: UPDATE student SET name='Alice' WHERE id = 100 wait_event: wait/synch/mutex/innodb/trx_mutex wait_source: trx0trx.cc:1234 blocker_info: Thread 42 waiting for wait/synch/mutex/innodb/trx_mutex这说明线程 42 在等 InnoDB 事务互斥锁，结合INNODB_TRX表就能找到持有锁的线程 ID。
5.4 构建「实验健康度」仪表盘（自动化验证脚本）
我把performance_schema查询封装成一个check_lab_health.sql，每次实验前运行它，自动生成报告：
-- check_lab_health.sql SELECT 'Lab01_Transaction' AS lab, COUNT(*) FILTER (WHERE EVENT_NAME = 'wait/synch/mutex/innodb/trx_mutex') AS trx_mutex_waits, AVG(TIMER_WAIT)/1000000000 AS avg_wait_sec FROM performance_schema.events_waits_history_long WHERE EVENT_NAME LIKE 'wait/synch/mutex/innodb/trx_mutex' AND TIMER_START > UNIX_TIMESTAMP(NOW() - INTERVAL 1 MINUTE) * 1000000000; -- 类似地检查 Lab02 的 index_read, Lab03 的 stored_program 等我的习惯：在run_all.sql最后一行加入SOURCE check_lab_health.sql;。如果某次实验trx_mutex_waits> 5，我就知道事务隔离实验的并发控制没到位，需要回溯SET TRANSACTION ISOLATION LEVEL是否生效。
希望帮到你。
本文还有配套的精品资源，点击获取
