企业官网建设流程全解析

简介：这是面向数据库课程设计的学生成绩管理系统完整设计文档，适合高校计算机相关专业学生完成课设或学习 Flask+MySQL 开发参考。内容基于 Python Flask 与 MySQL 实现管理员、教师、学生三类角色，覆盖系统总体设计、需求分析、概要设计、系统实现、测试总结五个章节，包含功能结构图、数据库概念/逻辑/物理设计、界面设计和主要程序代码；文档从项目背景、开发环境、业务需求与数据需求分析，到 E-R 图、数据表结构、核心功能代码和测试结论均有展开。可直接对照搭建单机可运行的成绩管理原型，理解选课、成绩录入、查询、权限管理等完整业务流程。资源共 1 个 doc 文件，约 3.95MB，排版完整，目录结构清晰，便于按章节查阅和二次修改。目前已有 5072 人学习下载，对于需要撰写课设报告、梳理设计思路和准备答辩的读者有较高参考价值。

1. 学生成绩管理系统：为什么说它是 MySQL 实战的“最小完整样本”

用 Excel 统计全班成绩翻车是什么体验？期末出分那天，你发现“张三”在两张表里一个叫“张 三”一个叫“张三”，VLOOKUP 匹配不到人；同一门课录了两条成绩，你根本不知道哪条是真的。这时候就该把成绩放进 MySQL 了。学生成绩管理系统是大到课程设计、小到教学处内部工具最常见的 MySQL 实战场景，它麻雀虽小但五脏俱全：三张业务表、主外键约束、增删改查、聚合统计、存储过程都能练到。本文从建表讲到 JDBC 连接、统计 SQL、触发器和排错，适合正在做课程设计，或者想用一套完整案例把 MySQL 基础串起来的人。你可以照着复现，也可以直接拿这套表结构改造成自己项目的起点。

2. 先建模再建表：学生、课程、成绩三表设计与约束落地

2.1 为什么必须拆成三张表，而不是一张大宽表

见过很多课程设计的开篇第一版，是做一张“成绩总表”，字段排开就是：学号、姓名、班级、课程名、老师、成绩。表面看录入方便，实际跑起来全是坑。一门课有期中、期末、补考三次成绩，你是加三列还是加三行？加三列，想再加一次平时成绩就得改表结构；加三行，学生和课程的信息就要重复存三遍，“张三”写成“张三 ”和“张三”还能不能匹配上全靠运气。

所以第一原则是遵循第三范式：学生信息单独存，课程信息单独存，成绩只存学生和课程的关联关系。学生表负责“谁考试”，课程表负责“考什么”，成绩表负责“考了多少分”。这样改一个学生的班级，只需要动一行；加一门新课，不需要动成绩表结构。反过来说，如果你要存的不只是总分，还有平时分、实验分、期末分，也应该拆成成绩明细表，而不是给 score 表加列——除非你已经确定这些分项永远不会单独参与统计和筛选。

还有一个容易被忽略的选型点：性别这类固定枚举值，用 TINYINT 加默认值 0 比用 VARCHAR 存“男/女”更稳。原因有三个，一是枚举值写错一个汉字就匹配不上，二是排序和 GROUP BY 时数字更快，三是后续如果出现“保密”以外的第三种状态，改字典表就行，不用动历史数据。热搜里说的“mysql 设置默认值为 0”，就是这个场景。

2.2 三张表的 DDL 落地：主键、唯一键、外键和字符集一次定好

建库建表这一步值得认真写，因为后面所有 SQL、所有 JDBC 代码都建立在这套表结构上。字符集直接上utf8mb4，别用 utf8，否则后面存 emoji 或者个别生僻字会报Incorrect string value。排序规则用utf8mb4_unicode_ci，对中文和拼音排序比general_ci更符合直觉。

CREATE DATABASE IF NOT EXISTS student_grade DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE student_grade; CREATE TABLE student ( student_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键', student_no VARCHAR(20) NOT NULL COMMENT '学号（业务编号）', student_name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT NOT NULL DEFAULT 0 COMMENT '0未知 1男 2女', birth_date DATE NULL COMMENT '出生日期', class_name VARCHAR(50) NULL COMMENT '班级', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (student_id), UNIQUE KEY uk_student_no (student_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表'; CREATE TABLE course ( course_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键', course_no VARCHAR(20) NOT NULL COMMENT '课程编号', course_name VARCHAR(100) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) NOT NULL DEFAULT 0.0 COMMENT '学分', teacher_name VARCHAR(50) NULL COMMENT '任课教师', PRIMARY KEY (course_id), UNIQUE KEY uk_course_no (course_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表'; CREATE TABLE score ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', student_id INT UNSIGNED NOT NULL COMMENT '学生ID，关联student', course_id INT UNSIGNED NOT NULL COMMENT '课程ID，关联course', score DECIMAL(5,2) NOT NULL COMMENT '成绩0-100，保留两位', exam_type TINYINT NOT NULL DEFAULT 1 COMMENT '1期中 2期末 3补考', exam_date DATE NULL COMMENT '考试日期', remark VARCHAR(255) NULL COMMENT '备注', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_student_course_exam (student_id, course_id, exam_type), KEY idx_course_score (course_id, score), CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';

这段 DDL 里有几个参数值得展开。student_id和course_id用INT UNSIGNED，别用INT，因为自增主键只可能为正数，无符号可以翻倍可用范围；score用DECIMAL(5,2)而不是FLOAT或DOUBLE，浮点数在二进制里无法精确表示 0.1，成绩累加平均后会出现 88.449999999 这种诡异小数，DECIMAL 是字符串存储的定点数，计算精确，成绩表一律用它。

唯一键uk_student_course_exam是这五张表里最重要的约束：它保证同一个学生、同一门课、同一种考试类型只能有一条成绩记录。这是对“同一条成绩录两遍”的第一道防线，靠程序去判断永远有漏洞。idx_course_score是联合索引，服务后面“按课程查成绩排名”的高频查询，把等值条件的course_id放前面，把范围条件的score放后面。外键约束在课程设计里一定要加，它能阻止你录入一个不存在的student_id，这是数据完整性的底线；如果以后上了分库分表或者数据量到了千万级，外键可能成为写入瓶颈，但一个学生成绩系统远没到那个量级，别学网上说“外键影响性能”就删掉它。

如果你想在数据库层再加一道成绩范围校验，MySQL 8.0.16 以后可以直接在 DDL 里加CONSTRAINT chk_score_range CHECK (score BETWEEN 0 AND 100)。8.0.16 之前 CHECK 子句会被解析但不会生效，所以如果服务器是 5.7，校验得靠触发器和应用层双重保证，这个放到第 4 章展开。

3. 用 JDBC 把它变成能用的系统：连接参数、PreparedStatement 与增删改查

3.1 连接参数：driver、URL 里那串参数到底在干什么

表建好了，下一步是用 Java 连上去。驱动用mysql-connector-java8.x，驱动类名是com.mysql.cj.jdbc.Driver，和 5.x 的com.mysql.jdbc.Driver不一样，别照旧教程抄错了。下面是获取连接的最简写法：

public static Connection getConnection() throws SQLException { String url = "jdbc:mysql://localhost:3306/student_grade" + "?useSSL=false" + "&serverTimezone=Asia/Shanghai" + "&characterEncoding=utf8mb4" + "&allowPublicKeyRetrieval=true"; String user = "root"; String password = "你的密码"; return DriverManager.getConnection(url, user, password); }

逐项说明。useSSL=false是因为本地开发库不需要 SSL 加密，不加这个 8.x 驱动有时会报 SSL 连接警告；serverTimezone=Asia/Shanghai必须加，否则驱动拿 JDBC 默认时区和 MySQL 会话时区对比，差了 8 小时，DATETIME字段读写会错位；characterEncoding=utf8mb4保证从 Java 字符串到 MySQL 的编码一致，不加它中文会变成问号；allowPublicKeyRetrieval=true是 MySQL 8.0 用caching_sha2_password认证时需要的，驱动首次连接要拿服务器公钥做 RSA 加密传输密码，没有这个参数会报Public Key Retrieval is not allowed。

连接池这里多说一句。课程设计阶段用DriverManager完全够，写清楚finally里关连接就行。等你部署到 Tomcat 或者 Spring Boot 里，再用 HikariCP 或者 Druid 替换，连接池的核心参数无非是maximumPoolSize、minimumIdle、connectionTimeout三个，这是后话，但面试常问。

3.2 PreparedStatement 完成增删改查：为什么绝不拼接字符串

增删改查里最容易翻车的是“动态条件拼接 SQL”。比如按姓名查学生，新手喜欢写：

String sql = "SELECT * FROM student WHERE student_name = '" + name + "'";

这就是经典 SQL 注入入口。用户输入一个' OR '1'='1，整张表就给你查出来了。正确做法是用PreparedStatement，参数用占位符?传进去，驱动会做转义和类型校验。

public List<Student> findByStudentName(String name) throws SQLException { String sql = "SELECT student_id, student_no, student_name, gender, class_name " + "FROM student WHERE student_name = ?"; List<Student> list = new ArrayList<>(); try (Connection conn = getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, name); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { Student s = new Student(); s.setStudentId(rs.getInt("student_id")); s.setStudentNo(rs.getString("student_no")); s.setStudentName(rs.getString("student_name")); s.setGender(rs.getByte("gender")); s.setClassName(rs.getString("class_name")); list.add(s); } } } return list; }

代码逻辑不复杂，说几个细节。try-with-resources会自动关闭Connection、PreparedStatement、ResultSet，顺序是从内到外，这比写finally里逐个判空关闭省心，也不会漏关连接。setString(1, name)的索引从 1 开始，不是 0。查询结果用列名取而不是列索引取，表结构加列时代码不容易错位。

如果成绩是按学号录的，而你没有学号对应的内部student_id，那更新语句就是两段式的。先查SELECT student_id FROM student WHERE student_no = ?，再用这个 ID 去操作score表。很多课程设计里“学号不存在但成绩录进去了”就是跳过了这一步。

更新一条成绩的 SQL 是UPDATE，热搜词里mysql update 语法经常被搜，核心是别忘记WHERE。一条没有 WHERE 的 UPDATE 会把整张表改成同一个值，这种事故在成绩系统里尤为常见，因为测试数据少，看不出问题，期末全量录成绩时一把梭，全班成绩变成一样。

UPDATE score SET score = ?, exam_date = ?, remark = ? WHERE student_id = ? AND course_id = ? AND exam_type = ?;

配合PreparedStatement，setBigDecimal给成绩，setDate给日期，注意 Java 的java.util.Date要转成java.sql.Date才能直接传。写完更新后先查一下受影响行数，executeUpdate()返回 0 说明 WHERE 条件没匹配到记录，这时候要明确提示用户“查无此人或该考试不存在”，而不是静默成功。

3.3 批量录入成绩：事务和 batch 的配合，别一千条 insert 跑半天

录入期末成绩往往是批量操作，一个班一门课几十上百行。一条一条循环 insert 也能用，但每次都有一次网络往返和事务提交，速度慢且一旦中途报错，前面录进去的和后面没录的会形成脏数据。这个场景用addBatch+ 手动事务。

public void batchInsertScore(List<ScoreRecord> records) throws SQLException { String sql = "INSERT INTO score(student_id, course_id, score, exam_type, exam_date) " + "VALUES (?, ?, ?, ?, ?)"; try (Connection conn = getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement(sql)) { for (ScoreRecord r : records) { ps.setInt(1, r.getStudentId()); ps.setInt(2, r.getCourseId()); ps.setBigDecimal(3, r.getScore()); ps.setByte(4, r.getExamType()); ps.setDate(5, r.getExamDate() != null ? new java.sql.Date(r.getExamDate().getTime()) : null); ps.addBatch(); } ps.executeBatch(); conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); } } }

核心逻辑是先把autoCommit关掉，所有 insert 攒在 batch 里，最后一次性提交。rollback()保证如果第 500 条失败了，前面 499 条也一起回滚，不会出现“录了一半没法交差”的尴尬。这里有个 MySQL 参数值得注意：rewriteBatchedStatements=true可以在 JDBC URL 后面加，驱动会把多条 INSERT 重写成一条多 VALUES 语句，性能提升非常明显，不加的话 batch 只是客户端攒着，服务端还是一条一条执行。

事务粒度也要控制。一个班一次考试的成绩是一个事务，别把整个年级所有班放在一个事务里跑，锁范围太大，后面别的连接更新成绩会被堵住，这就是第 5 章要讲的锁等待问题。

4. 成绩统计与自动化：聚合查询、视图、存储过程与触发器的 SQL 落地

4.1 聚合统计：GROUP BY 和 HAVING 的顺序别搞反

系统里录入成绩只是第一步，真正给老师看的是统计结果：每门课的平均分、最高分、最低分、及格率。这些用一条聚合 SQL 就能算完，不要写 Java 查出全表再慢慢累加。下面是每门课的成绩汇总：

SELECT c.course_name, COUNT(sc.id) AS exam_count, ROUND(AVG(sc.score), 2) AS avg_score, MAX(sc.score) AS max_score, MIN(sc.score) AS min_score, SUM(CASE WHEN sc.score >= 60 THEN 1 ELSE 0 END) / COUNT(sc.id) AS pass_rate FROM course c LEFT JOIN score sc ON c.course_id = sc.course_id GROUP BY c.course_id, c.course_name HAVING COUNT(sc.id) > 0 ORDER BY avg_score DESC, c.course_name ASC;

筛选和排序的底层执行顺序要知道：WHERE 在 GROUP BY 之前过滤原始行，HAVING 在 GROUP BY 之后过滤分组。想查“平均分低于 60 的课程”用HAVING AVG(sc.score) < 60，这个条件放 WHERE 里会直接报错，因为 WHERE 执行时还没有分组。ONLY_FULL_GROUP_BY模式下，SELECT 里的列必须是 GROUP BY 的列或者聚合函数，MySQL 5.7 开始默认开启，所以 GROUP BY 后面写了c.course_id, c.course_name，SELECT 里才能原样查出course_name。

LEFT JOIN 而不是 INNER JOIN，是为了把没人选或者没人考试的课程也显示出来。如果一门课一条成绩都没有，COUNT(sc.id)是 0，AVG是 NULL，HAVING 条件就把这行过滤掉了，这点要根据需求决定保留还是过滤。ORDER BY 里avg_score DESC后面再加一个course_name ASC，是让平均分相同的课程按名称排序，这样多次查询结果顺序稳定。

按学生统计同样思路：每个学生的平均分、总分、选课门数。ORDER BY 总分 DESC就是年级排名。要注意的是排名并列时的处理，如果要求“同分同名次”，用窗口函数DENSE_RANK()，MySQL 8.0 直接支持；5.7 没有窗口函数，只能用自连接或者变量实现，这个边界要心里有数。

4.2 视图：把高频统计 SQL 固化成一张“虚拟表”

每次打开页面都跑一遍上面那种多表 JOIN 的聚合 SQL，麻烦不说，还容易写错。视图就是把这些复杂查询存成数据库对象，Java 端直接SELECT * FROM v_student_grade_summary就能拿到结果。它不是物理表，数据还是存在原表里，视图只是保存了 SQL 定义。

CREATE OR REPLACE VIEW v_student_grade_summary AS SELECT s.student_no, s.student_name, c.course_name, sc.score, sc.exam_type, c.credit, CASE WHEN sc.score >= 60 THEN '及格' WHEN sc.score IS NULL THEN '缺考' ELSE '不及格' END AS grade_level FROM student s JOIN score sc ON s.student_id = sc.student_id JOIN course c ON c.course_id = sc.course_id;

注意视图的性质：它是只读的“查询映射”，如果要对视图执行UPDATE，MySQL 要求视图的 SELECT 不能有聚合、DISTINCT、JOIN 等复杂结构，所以像这种多表 JOIN 视图不要试图去 UPDATE，新增成绩还是走原始表。视图的真正价值在于把统计口径固定下来，比如“及格”的定义以后要改成 55 分，只需要改视图定义，Java 代码不用动。这也解释了为什么很多数据报表系统会建一套视图层——它是程序代码和原始表结构之间的缓冲带。

4.3 存储过程：按学号课程号录成绩，调用端不用知道内部 ID

存储过程在这个系统里的价值，是把“按业务编号录入成绩”的整套逻辑下沉到数据库里。调用方只需要传学号、课程号、分数、考试类型，存储过程内部负责把编号换成内部 ID、校验存在性、处理重复插入。省掉的是一堆 Java 代码里的查 ID 逻辑。

DELIMITER $$ CREATE PROCEDURE sp_insert_score( IN p_student_no VARCHAR(20), IN p_course_no VARCHAR(20), IN p_score DECIMAL(5,2), IN p_exam_type TINYINT ) BEGIN DECLARE v_student_id INT UNSIGNED; DECLARE v_course_id INT UNSIGNED; SELECT student_id INTO v_student_id FROM student WHERE student_no = p_student_no LIMIT 1; IF v_student_id IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '学号不存在，请检查'; END IF; SELECT course_id INTO v_course_id FROM course WHERE course_no = p_course_no LIMIT 1; IF v_course_id IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '课程编号不存在，请检查'; END IF; INSERT INTO score (student_id, course_id, score, exam_type) VALUES (v_student_id, v_course_id, p_score, p_exam_type); END$$ DELIMITER ;

参数前缀p_是避免和列名混淆的约定，DECLARE声明的变量用v_前缀，这样一眼能看出是常量、入参还是内部变量。SIGNAL SQLSTATE '45000'是主动抛异常，调用方能捕获到错误消息“学号不存在，请检查”。LIMIT 1是保险写法，student_no有唯一键约束，正常情况只可能查到一行，但加了它不会因为意外数据导致SELECT INTO报错。

触发存储过程最简单的办法是命令行或者 JDBC 里直接调用：

CALL sp_insert_score('2024001', 'CS101', 88.5, 2);

存储过程里还能加更多业务逻辑，比如判断成绩是否在 0-100 之间、判断是否补考冲突、写一条操作日志。但我的建议是存储过程只放和数据一致性强相关的逻辑，业务规则放在应用层，否则规则分散在 Java 和 SQL 两处，改起来要同步上线，这是个长期维护成本问题。

4.4 触发器：录入成绩前自动拦一道

热搜词里“mysql 中触发器中分隔符”被反复搜，就是因为写触发器必须先把分隔符改成$$，否则BEGIN里的分号会被 mysql 命令行当成语句结束。触发器适合做“无论谁、无论用什么方式插入成绩，都要经过这道校验”的兜底。这里写一个插入前校验成绩范围的触发器：

DELIMITER $$ CREATE TRIGGER trg_score_before_insert BEFORE INSERT ON score FOR EACH ROW BEGIN IF NEW.score < 0 OR NEW.score > 100 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '成绩必须在0到100之间'; END IF; IF NEW.exam_type NOT IN (1, 2, 3) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '考试类型只能为1(期中)、2(期末)、3(补考)'; END IF; END$$ DELIMITER ;

NEW表示即将插入的新行，NEW.score就是本次要写入的成绩。这个触发器对INSERT和UPDATE分别写，UPDATE的校验要建BEFORE UPDATE触发器，或者直接在 UPDATE 语句里用WHERE score BETWEEN 0 AND 100做应用层过滤，两种实现各有取舍。

触发器最大的坑是隐蔽和难排查。一条 INSERT 触发的逻辑出错，应用端只看到“触发器中出错”，日志里没有具体行和原因。而且触发器里不能再查改同一张表同一行，否则会无限递归。还有，复制架构下触发器只在源库执行，主从切换可能出现两边数据不一致。所以我的原则是：触发器只用来做轻量校验和审计日志，重统计逻辑一概不往里放，这样出问题能快速定位。

5. 避坑排查：字符集、锁表、连接数与成绩精度的真实事故

本章写几条我从实际开发和课程设计辅导里见过的典型翻车现场，全部按“现象、原因、解决”的路子来，你可以直接对号入座。

5.1 成绩小数位变成 88.449999999

现象：往 score 表插入 88.45，查出来是 88.449999999，四舍五入后的平均值也不对。 原因：表字段用的是 FLOAT 或者 DOUBLE。浮点数在 MySQL 内部按二进制存储，无法精确表示 88.45 这种十进制小数，属于硬件层面的表示误差，不是 bug。 解决：把成绩字段统一改成DECIMAL(5,2)。DECIMAL是定点数，底层按字符串存储，计算时精确。修改语句：

ALTER TABLE score MODIFY COLUMN score DECIMAL(5,2) NOT NULL COMMENT '成绩0-100，保留两位';

改完以后，之前插入的错误浮点值并不会自动修复，需要重录或重算一遍，这就是为什么建表初期就该用对类型。成绩表的“两位小数”是业务刚需，别听“用 DOUBLE 精度够”的话，平均分、绩点计算一多，误差就攒出问题了。

5.2 中文乱码：插入“张三”变成“????”

现象：Java 端插入中文，数据库表里显示????，或者查出来乱码。 原因：三层有一处不一致就会乱——连接 URL 没加characterEncoding=utf8mb4，数据库或表字符集不是 utf8mb4，MySQL 服务端character_set_server配置不对。 解决：三层统一。连接 URL 补上characterEncoding=utf8mb4，表结构重建为DEFAULT CHARSET=utf8mb4或执行：

ALTER TABLE student CONVERT TO CHARACTER SET utf8mb4;

重点排查方向是连接参数，Java 端最容易漏的就是它。命令行里插入中文正常而 Java 乱码，基本可以确定为 URL 缺参。注意utf8mb4是utf8的超集，不是替代品，老表的utf8数据如果只是普通汉字，改到utf8mb4不会损坏。

5.3 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'

现象：命令行连 MySQL 报这个错，Java 端报Communications link failure。 原因：MySQL 服务没启动，或者客户端默认找的 socket 文件和实际路径不一致。热词里搜到的错误码2002基本都属于这一类。常见于刚装好 MySQL 还没systemctl start mysql，或者 Linux 上 socket 路径配置在/var/run/mysqld/mysqld.sock而客户端找/tmp。 解决：先确认服务状态，再检查 socket 路径：

systemctl status mysql mysql -u root -p -h 127.0.0.1 -P 3306

-h 127.0.0.1会走 TCP 而不是 socket 文件，能绕开路径问题。如果 TCP 能连而 socket 不能连，编辑/etc/my.cnf里的[mysqld]段，加上socket = /tmp/mysql.sock并重启服务。这个报错只有一个好处——它直接告诉你 MySQL 没起来，排查方向明确。

5.4 成绩更新卡住不动，报 lock wait timeout exceeded

现象：执行一条 UPDATE 语句瞬间卡住，几十秒后报Lock wait timeout exceeded; try restarting transaction。 原因：另一个连接开启事务后没有提交或回滚，它持有的行锁一直不释放。这个系统里最常见的场景是批量录入成绩时开了事务忘记 commit，然后别的连接去更新同一行成绩。 解决：先找出持锁事务，再按需处理：

SELECT trx_id, trx_state, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx;

找到trx_mysql_thread_id后用KILL <线程ID>把僵死事务干掉。日常习惯上，应用层统一用第 3 章的 try-with-resources 模式，事务finally里一定保证commit或rollback执行。也可以把连接池的maxLifetime调短，避免连接被捡回来时还带着上一个未提交事务。

5.5 MySQL 8.0 用 Navicat 或老 JDBC 驱动连不上：caching_sha2_password authentication

现象：Navicat 连接时报Authentication plugin 'caching_sha2_password' cannot be loaded，或者老版本 JDBC 连不上。 原因：MySQL 8.0 默认认证插件改成了caching_sha2_password，老版本客户端不认识。Navicat 16 以上已适配，旧版和 mysql-connector-java 5.x 会报错。 解决：不升级客户端的话，把账户改回旧插件：

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

mysql_native_password的加密强度比caching_sha2_password低，生产环境建议直接升级驱动，而不是降低安全等级。这个坑只在初始化环境时碰到，踩一次后建议在安装笔记里直接写上“连接 8.0 必须用 8.x 驱动”这条。

6. 再往前走一步：索引设计、mysqldump 备份与一条慢查询的定位

系统跑起来以后，真正让成绩管理从“能跑”变成“好用”的，是索引优化、备份策略和慢查询排查这三件事。

成绩表上目前有一个联合索引idx_course_score(course_id, score)。高频查询是“按课程查成绩排名”和“按学生查所有成绩”，后者走的是uk_student_course_exam唯一索引的前缀。用EXPLAIN验证一下：

EXPLAIN SELECT s.student_name, sc.score FROM score sc JOIN student s ON sc.student_id = s.student_id WHERE sc.course_id = 1 ORDER BY sc.score DESC;

看type列，理想情况是ref或range；如果是ALL，说明全表扫了 10 万行，此时再加一个(course_id, score)联合索引能让排序也走索引，避免 filesort。判断索引是否够用，不要靠猜，EXPLAIN的key和rows两列会告诉你真相。

备份这个习惯很多人一开始就忽略。课程设计也好，小系统也好，至少每天一次逻辑备份：

mysqldump -u root -p --single-transaction --default-character-set=utf8mb4 \ student_grade > student_grade_$(date +%F).sql

--single-transaction让备份不锁表，InnoDB 下用一致性快照，成绩录入中的事务不受影响。恢复时mysql -u root -p student_grade < student_grade_2025-01-01.sql，一条命令的事。我吃过亏才养成的习惯是：备份脚本必须跑一遍恢复演练，而不是备份完扔在那里不管，否则真到要恢复时才发现备份文件是坏的，那种感觉比考试考砸了还难受。

慢查询的定位路径也很简单。打开慢查询日志，超过阈值的 SQL 会被记录下来：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;

然后跑两小时业务，再去看mysqld-slow.log。对成绩系统来说，出现慢查询九成是索引没打到，少数是统计 SQL 里LIKE '%关键字%'没走索引，这种查询在 10 万行以上的成绩表就会退化到秒级。改进方向是让LIKE条件改成前缀匹配，或者把统计结果放进一张汇总表定时刷新，而不是实时扫明细。

我的习惯是，每写完一个功能，顺手用EXPLAIN验一下它最核心的那条查询，再花五分钟把备份命令加到 crontab 里。这套动作做完，学生成绩管理系统才算是真的落地了，不是交完作业就散架。希望这些推进和建议能帮你把系统做得比“能跑”更进一步，真正敢把成绩数据托付给它。

本文还有配套的精品资源，点击获取