企业官网建设流程全解析

简介：数据库课程设计参考：MySQL学生成绩管理系统，基于Python Flask与MySQL开发，采用前后端分离架构，包含管理员、教师、学生三类用户角色。系统支持成绩录入、修改、删除、查询，学生在线选课与查看个人成绩，教师管理课程并统计不同分数段人数，管理员维护学生、教师、课程、专业及选课信息，覆盖了数据库课程设计的典型业务场景。资源包共1个doc文件，大小约3.95MB，内容为完整课程设计报告，章节涵盖系统总体设计、需求分析、概要设计、数据库概念结构设计、逻辑结构设计、物理设计、界面实现与核心程序代码、测试与总结，并附有功能结构图和数据流说明，清晰呈现从需求到实现的完整过程。已有5072人学习，适合计算机相关专业学生作为课程设计参考资料，可借鉴其设计思路、文档结构及Python+Flask+MySQL实现方式，也可直接用于撰写数据库课程设计报告。

1. 学生成绩管理系统：建表设计比写功能更值得先动手

把“MySQL学生成绩管理系统”丢给搜索引擎，翻出来的大半是课程设计和毕业设计。但这个题目被写烂了不代表它简单，恰恰相反，我见过太多人把全部精力花在 JSP、Servlet 和前端表格上，最后卡死在成绩表的关联查询、乱码和连不上 MySQL。多数翻车现场，问题不在功能代码，而在最容易被忽略的数据库设计。这个系统本质上就干三件事：管学生、管课程、管成绩，但“成绩”和“学生”“课程”之间的关联方式、字段类型、索引和约束，决定了你是花一个晚上跑通演示，还是花一个礼拜在报告里解释“为什么查不出平均分”。

这篇文章只聊数据库侧的完整落地路径。适合三类人：课程设计需要交系统的人，刚入职要接手公司内部成绩/培训管理模块的初级开发，以及想用 MySQL 练手把建表、存储过程、触发器和 JDBC 连接串一遍的人。你会看到我从实体关系到建库脚本，再到核心查询、存储过程、触发器和 JavaWeb 对接的完整方案，以及每条踩过的坑。目标很直接：照着做，能跑通；做完，敢把这份设计写进简历。

2. 从需求到三大实体表：学生、课程、成绩的表结构设计与建库脚本

2.1 三张核心表的字段拆解：不冗余、可扩展、能对账

学生成绩管理系统的数据库侧核心就是“学生 - 课程 - 成绩”三张表。绝大多数的设计翻车，都是在这三张表的字段上自作聪明。常见错误是：在学生表里直接存“总分”“平均分”，在成绩表里用学生姓名做关联字段，或者把三个学期的成绩拆成三列。

先说学生表。字段至少要覆盖：学号、姓名、性别、班级、入学年份。学号必须单独设置唯一索引。有人习惯直接用自增主键id关联一切，但业务上方方面面认的是学号，报表、导入导出、与其他系统对接全靠它。所以正确做法是：主键用id，学号stu_no加UNIQUE KEY。

课程表相对简单：课程号、课程名、学分、授课教师。注意学分要用DECIMAL(3,1)而不是INT，因为很多学校有 0.5 学分；授课教师不要单独建教师表——除非你确定后面要做教师模块，否则一个VARCHAR存姓名就够了，这就是“能扩展但不过度设计”。

成绩表是最容易出问题的地方。一个学生同一门课，可能存在补考、重修多条记录，所以不要把主键设成(stu_id, course_id)联合主键，否则补考记录会把首次考试成绩覆盖掉。正确设计是用自增主键，stu_id和course_id各建普通索引用于关联查询。成绩字段类型选DECIMAL(5,2)，满分 100 保留两位小数足够；如果以后可能有“通过/不通过”制，再额外加一个VARCHAR结果字段，不要动成绩字段本身。学期字段semester用VARCHAR(20)存“2024-2025-1”这类格式，可读性好且不会出现年份边界问题。最后加一个create_time记录录入时间，这对排查“谁什么时候改的成绩”非常有用。

2.2 建库建表SQL脚本：引擎、字符集、索引与约束的一次到位

确认了字段，接下来直接给建库脚本。我一般会在项目根目录放一个init.sql，保证任何人拿到代码都能在本地重建环境。

-- 建库：utf8mb4 是 MySQL 5.7+ 的默认推荐字符集 CREATE DATABASE IF NOT EXISTS score_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE score_db; -- 学生表 CREATE TABLE `student` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '内部主键', `stu_no` VARCHAR(20) NOT NULL COMMENT '学号，业务唯一标识', `stu_name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT NOT NULL DEFAULT 1 COMMENT '1-男 0-女', `class_name` VARCHAR(50) NOT NULL COMMENT '班级名称', `enroll_year` YEAR NOT NULL COMMENT '入学年份', PRIMARY KEY (`id`), UNIQUE KEY `uk_stu_no` (`stu_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表'; -- 课程表 CREATE TABLE `course` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `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` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '授课教师', PRIMARY KEY (`id`), UNIQUE KEY `uk_course_no` (`course_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表'; -- 成绩表 CREATE TABLE `score` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `stu_id` INT UNSIGNED NOT NULL COMMENT '学生表id', `course_id` INT UNSIGNED NOT NULL COMMENT '课程表id', `semester` VARCHAR(20) NOT NULL COMMENT '学期，如 2024-2025-1', `score` DECIMAL(5,2) NOT NULL DEFAULT 0.00 COMMENT '成绩', `makeup_count` TINYINT NOT NULL DEFAULT 0 COMMENT '补考次数', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_stu_id` (`stu_id`), KEY `idx_course_id` (`course_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';

几个容易被忽视的点。引擎必须用 InnoDB，这是为了支持事务和外键；MyISAM 在课程设计阶段跑起来感觉没差别，一旦用到事务和行级锁就翻车。字符集统一utf8mb4，不要用utf8——utf8在 MySQL 里最多存 3 字节，遇到生僻字或 emoji 会报Incorrect string value错误，这条几乎是所有中文乱码问题的根源。

建表顺序也重要：先建student和course，再建引用它们的score。如果你有外键需求，应该在score表里补上FOREIGN KEY，但我在课程设计阶段一般不建物理外键，原因后面单讲。索引方面，score表的stu_id和course_id必须建索引，否则等成绩表数据过万，关联查询会直接慢到让人怀疑服务器挂了。

2.3 补充历史成绩与学期维度：别等做报表时才改表

很多人的第一版成绩表只有student_id、course_id、score三个字段，做到“查看历史成绩”或“按学期统计绩点”时才傻眼，那时候改表就要动已经写好的代码。我的习惯是第一版就把semester字段带上，哪怕页面暂时用不到。同理，makeup_count补考次数看起来没用，但做“成绩预警”和“补考名单”两个功能时会直接省掉一次大改。

如果你在导入 Excel 成绩时发现日期变成了乱码或字符串，根源基本是字符集或字段类型。成绩表里的时间字段统一用DATETIME或TIMESTAMP，不要用VARCHAR存时间。如果已有脏数据是字符串格式，可用STR_TO_DATE转换后再更新：

-- 把字符串时间列统一成 DATETIME 的常见修复语句 UPDATE score SET create_time = STR_TO_DATE('2024/06/30 10:00:00', '%Y/%m/%d %H:%i:%s') WHERE create_time IS NULL;

STR_TO_DATE的第二个参数必须和第一个参数的实际格式完全对应，%Y是四位年份，%y是两位。这里最容易踩的坑是月份和日期写反——用了%m/%d解析2024/13/45这类值会返回 NULL 而不是报错，数据就静默丢了。所以跑完 UPDATE 后一定要先SELECT COUNT(*)对比一下受影响行数。

3. 把核心查询写成能体现水平的SQL：排序、分组统计与窗口函数

3.1 成绩排序与总分排名的三种写法

学生成绩系统最核心的输出就是“成绩单”和“排名”。排名看似简单，但“同分怎么排”这个需求能筛掉一半的 SQL 写法。最土的写法是直接ORDER BY score DESC，但这样只能看出顺序，看不出“第几名”。

这里给出三种排名写法，从简单到进阶：

-- 写法一：直接排序，适合成绩单展示 SELECT stu_no, stu_name, course_name, score FROM score s JOIN student st ON s.stu_id = st.id JOIN course c ON s.course_id = c.id WHERE s.semester = '2024-2025-1' ORDER BY score DESC;

-- 写法二：MySQL 8.0 之前用用户变量实现排名 -- @rank 是用户变量，每行 +1；@last_score 记录上一行成绩，同分同名次 SET @rank := 0, @last_score := NULL; SELECT stu_no, stu_name, score, @rank := @rank + 1 AS rank_no, IF(@last_score = score, @rank - 1, @rank) AS actual_rank, @last_score := score FROM ( SELECT st.stu_no, st.stu_name, s.score FROM score s JOIN student st ON s.stu_id = st.id WHERE s.course_id = 1 ORDER BY s.score DESC ) t;

-- 写法三：MySQL 8.0 窗口函数，最简洁 -- RANK() 同分同名次且跳号：1、1、3 -- DENSE_RANK() 同分同名次不跳号：1、1、2 SELECT stu_no, stu_name, score, RANK() OVER (ORDER BY score DESC) AS rank_skip, DENSE_RANK() OVER (ORDER BY score DESC) AS rank_no_skip FROM score s JOIN student st ON s.stu_id = st.id WHERE s.course_id = 1;

写法一适合打印成绩单，写法二适合 MySQL 5.7 及以下版本，写法三只适用于 MySQL 8.0+。三种写法的执行计划差别很大：用户变量方案需要在子查询里先排序，意味着额外一次排序操作；窗口函数则可以在同一趟扫描里完成。如果只是课程设计或内部小系统，写法一就够了，但你要知道写法二和三的存在，因为面试一定会问。

3.2 按班级/课程分组统计：GROUP BY 与 SQL_MODE 的坑

统计“每个班每门课的平均分、最高分、及格率”是成绩系统的必备报表。这里最大的坑是 MySQL 5.7 及以上默认开启ONLY_FULL_GROUP_BY，也就是SELECT的非聚合列必须全部出现在GROUP BY里。很多人写下面的语句会直接报错：

-- 报错示例：sql_mode 包含 ONLY_FULL_GROUP_BY 时，stu_name 不在 GROUP BY 中 SELECT st.stu_name, c.course_name, AVG(s.score) FROM score s JOIN student st ON s.stu_id = st.id JOIN course c ON s.course_id = c.id GROUP BY st.stu_name, c.course_name;

解决方式有两个。正规做法是只按业务维度分组：

-- 正确做法：只分组到班级和课程维度 SELECT st.class_name, c.course_name, COUNT(*) AS exam_count, AVG(s.score) AS avg_score, MAX(s.score) AS max_score, MIN(s.score) AS min_score, ROUND(SUM(CASE WHEN s.score >= 60 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS pass_rate FROM score s JOIN student st ON s.stu_id = st.id JOIN course c ON s.course_id = c.id WHERE s.semester = '2024-2025-1' GROUP BY st.class_name, c.course_name ORDER BY st.class_name, avg_score DESC;

这条语句同时覆盖了分组、聚合和条件计数。SUM(CASE WHEN ... THEN 1 ELSE 0 END)是计算及格人数的经典写法，比COUNT(IF(...))可读性更好。如果你确实想关闭严格模式，可以执行SET sql_mode = 'STRICT_TRANS_TABLES'，但我不建议在项目里这么做，因为ONLY_FULL_GROUP_BY能挡住大量由于分组不当导致的统计错误。

3.3 用存储过程封装成绩录入：参数校验与事务控制

存储过程在你的系统里不一定用得到，但课程设计报告里写“使用存储过程封装成绩录入逻辑”，是一个很好的加分项。更现实的价值是：你可以把“录入成绩前检查学生是否存在、课程是否存在、成绩是否在 0-100 之间”这些业务规则全部塞进数据库，Java 端写代码会简化很多。

DELIMITER $$ CREATE PROCEDURE `sp_insert_score`( IN p_stu_no VARCHAR(20), IN p_course_no VARCHAR(20), IN p_semester VARCHAR(20), IN p_score DECIMAL(5,2) ) BEGIN DECLARE v_stu_id INT; DECLARE v_course_id INT; -- 校验成绩范围，不满足则抛异常终止 IF p_score < 0 OR p_score > 100 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'score must be between 0 and 100'; END IF; -- 根据业务编号查询内部 id SELECT id INTO v_stu_id FROM student WHERE stu_no = p_stu_no; IF v_stu_id IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'student not found'; END IF; SELECT id INTO v_course_id FROM course WHERE course_no = p_course_no; IF v_course_id IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'course not found'; END IF; -- 事务保证：要么全部写入，要么全部回滚 START TRANSACTION; INSERT INTO score (stu_id, course_id, semester, score) VALUES (v_stu_id, v_course_id, p_semester, p_score); COMMIT; END$$ DELIMITER ;

这里的三个关键点。第一，DELIMITER $$是必须的，因为默认的;分隔符会让 MySQL 在遇到存储过程内部第一句的;时误以为语句结束，这是初学者最常遇到的“语法一直报错”原因。第二，SIGNAL SQLSTATE '45000'是 MySQL 5.6 之后推荐的抛自定义异常方式，45000是通用用户异常状态码；MESSAGE_TEXT会被上层 JDBC 捕获到SQLException.getMessage()里。第三，变量v_stu_id如果查询不到，SELECT INTO不会赋 NULL，而是直接报NO DATA异常，所以更稳的写法是先用SELECT COUNT(*)判断，或者声明NOT FOUND的 handler 再捕获，这里为了让初次接触的人理解，用了IF IS NULL兜底——实操中你会发现它也能工作，因为SELECT INTO查不到时会把变量置 NULL 并产生 warning，在存储过程中默认不会中断。

调用这个存储过程的方式很简单：

CALL sp_insert_score('2024001', 'CS101', '2024-2025-1', 87.5);

存储过程的调试比普通 SQL 难得多，因为 MySQL 的存储过程没有像样的断点调试器。我的经验是：先在存储过程外面用普通SELECT把每一段逻辑跑通，确定无误后再包进过程体；遇到问题就用SELECT v_stu_id这种临时输出看中间值，排查完再删掉。这条血泪经验能救你至少两小时的命。

4. 触发器与视图：让系统自动维护统计数据的常见设计

4.1 触发器做成绩合法性校验和统计表联动

在系统里，成绩录入可能有多个入口：Java 管理端、Excel 导入、存储过程。如果校验逻辑只写在一处，别的入口就会绕过。触发器的作用就是把“成绩必须 0-100”这条底线直接钉死在数据库层面。

-- 成绩录入合法性校验触发器 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 = 'score out of range'; END IF; -- 同一学生同一课程同一学期只保留一条成绩记录 IF EXISTS ( SELECT 1 FROM score WHERE stu_id = NEW.stu_id AND course_id = NEW.course_id AND semester = NEW.semester ) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'duplicate score record'; END IF; END$$ DELIMITER ;

这段触发器解决了两个典型的业务漏洞。第一是脏数据拦截，不管是程序 bug 还是手工 SQL 误操作，score > 100的记录永远进不了表。第二是重复成绩的防线——虽然 Java 层可以先去查一次再做 insert，但并发场景下两个请求同时查到“不存在”然后同时插入，触发器才是最终防线。这里NEW.xxx表示新插入行的字段值，OLD.xxx对应更新前或删除前的值，这是触发器的基本语法，必须掌握。

如果你需要维护一张成绩统计汇总表，比如“班级平均分表”，可以在score表上建AFTER INSERT触发器去更新汇总表。但这里有个隐藏的坑：触发器里不能直接查询自己所在表，所以在统计表中更新数据时不要依赖触发器的执行顺序。更稳妥的常见做法是不要做实时统计，而是在报表查询时用视图实时计算。数据量在十万条以内，视图实时计算的性能完全够用，别为了“性能优化”自找麻烦。

4.2 视图简化复杂查询：平均分、及格率、排名视图

视图的价值在于把复杂 SQL 封装成“虚拟表”，Java 端只需要SELECT * FROM v_class_score_stats，不用关心背后是几个 JOIN 和 GROUP BY。这对课设答辩也很有效——演示时翻出视图定义文件，比现场敲 SQL 更有说服力。

-- 班级-课程成绩统计视图 CREATE OR REPLACE VIEW `v_class_course_stats` AS SELECT st.class_name, c.course_name, ROUND(AVG(s.score), 2) AS avg_score, COUNT(*) AS student_count, ROUND(SUM(CASE WHEN s.score >= 60 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS pass_rate, MAX(s.score) AS max_score, MIN(s.score) AS min_score FROM score s JOIN student st ON s.stu_id = st.id JOIN course c ON s.course_id = c.id GROUP BY st.class_name, c.course_name;

创建后可以直接查询：

SELECT * FROM v_class_course_stats WHERE class_name = '计科2301' ORDER BY avg_score DESC;

如果后续要加“总分排名视图”，就是在前面窗口函数基础上做成视图。注意CREATE OR REPLACE VIEW只能替换同名的视图，如果要把视图改成基表，需要先DROP VIEW。还有一点：视图底层 SQL 里有ORDER BY在多数场景下会被忽略，排序需求应该在查询视图时显式ORDER BY，不要依赖视图内部的排序定义。

4.3 为什么我不建议在课程设计里用物理外键

这是我和很多人意见不一致的地方。正规教材会让你建外键保证引用完整性，但我一般建议在成绩表上只建索引、不建物理外键。原因有四条：第一，物理外键会导致每次INSERT INTO score都去检查student和course的对应行，在批量导入成绩时性能成倍下降；第二，删除学生时必须先删成绩，否则报外键约束错误，对课设这种经常需要清库重来的场景非常碍事；第三，学生系统的数据量通常不大，应用层代码完全可以在写入前先SELECT检查；第四，如果哪天想分库分表，物理外键是第一个要拆掉的包袱。

那什么时候该用物理外键？当系统里有多个前端入口、且不允许任何脏关联数据存在时，比如电商订单表和用户表。学生成绩系统用触发器 + 应用层双重校验，已经能实现同样的效果。

5. JavaWeb对接MySQL：连接池配置与6个高频连接故障排查

5.1 JDBC连接参数：时区、SSL、驱动版本

有了数据库和存储过程，下一步就是让 JavaWeb 项目连上来。这一节集中解决“MySQL 装好了、脚本跑通了、Java 连不上”的问题。如果你用 Navicat 或 MySQL Workbench 能连上，但 Java 连不上，问题几乎都出在连接串参数上。

最稳的 JDBC 连接串模板：

jdbc:mysql://localhost:3306/score_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&rewriteBatchedStatements=true

逐个参数说明。useSSL=false是必须的，MySQL 8.0 默认开启 SSL，但本地开发环境基本都没有配证书，不关掉会报Communications link failure或者 SSL 握手错误。serverTimezone=Asia/Shanghai解决时区错误，MySQL 8.0 默认时区是 UTC，不指定的话 Java 连接会报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，这一串乱码就是因为 MySQL 没找到合适的时区描述。allowPublicKeyRetrieval=true是 MySQL 8.0 用caching_sha2_password认证插件时的必选项，不开启会报Public Key Retrieval is not allowed，这条在 Navicat 上不出现是因为客户端自己实现了密钥交换。rewriteBatchedStatements=true是性能关键，批量插入成绩时它能将多条 insert 合并成一条多值 insert，速度提升数倍。

驱动版本和 MySQL 版本必须匹配。MySQL 5.7 用mysql-connector-java 5.1.x没问题，但 5.1.x 连 MySQL 8.0 会直接报Unsupported major.minor version之类错误。常见选择是：MySQL 8.0 配mysql-connector-j 8.0.x，MySQL 5.7 配mysql-connector-java 5.1.49。不要无脑下最新版，兼容性第一。

5.2 数据库连接池的常用配置

课程设计里有人直接用DriverManager.getConnection()每次新建连接，这样演示没问题，但并发一上来就会出现连接超时。标准做法是配连接池。如果是 Spring Boot 项目，HikariCP 是默认选项，配置如下：

spring: datasource: url: jdbc:mysql://localhost:3306/score_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000

这些参数的含义：minimum-idle是池里最少保持的闲置连接数，maximum-pool-size是最大连接数——课设系统 20 足够，不要再大，连接数不是越大越快，MySQL 默认最大连接数是 151，你设置 100 会直接把数据库拖垮。connection-timeout是等待连接的最长时间，30 秒没拿到连接就抛异常，比客户端无限等要好排查得多。max-lifetime是连接最大存活时间，要小于 MySQL 的wait_timeout默认 8 小时，否则连接会被 MySQL 服务端默默断开，Java 还拿着旧连接去用就报Connection is not available。

5.3 高频连接故障排查

记录几条真正高频的坑。第一条是ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'。这个错误发生在 Linux 上，服务端可能没启动，或者 socket 文件实际路径不在/tmp。先执行systemctl status mysqld或service mysql status确认进程活着；活着再看my.cnf里的socket配置，常见路径是/var/lib/mysql/mysql.sock，用mysql -uroot -p -S /var/lib/mysql/mysql.sock测试。Java 端一般走 TCP 不走 socket，所以这个错误主要发生在命令行连接时。

第二条是Public Key Retrieval is not allowed。很多人会建议直接关掉 caching_sha2_password，改成mysql_native_password。能用但有代价：新版 MySQL 已默认弃用旧认证。更干净的办法就是在连接串加allowPublicKeyRetrieval=true，这是官方提供的合法开关，不是旁门左道。

第三条是中文乱码。现象是数据库里看到的是中文，Java 端查出来是???，或者反过来。原因基本都是连接串没加characterEncoding=utf8，或建库时用了latin1。检查顺序：先看建库语句的DEFAULT CHARSET，再看连接串，最后SET NAMES utf8mb4。绝大多数情况是连接串少了个参数。

第四条是Unknown database 'score_db'。这不是权限问题，是连接串里的库名写错了，或者你还停留在默认test库。先SHOW DATABASES确认库名大小写，MySQL 的库名在 Linux 下是大小写敏感的。

第五条是连接池耗尽。现象是系统跑一会儿后查询全部超时，SHOW PROCESSLIST看到大量Sleep连接。原因是连接池最大连接数设置太大，或代码里没有正确关闭ResultSet、Statement。排查方法是压低maximum-pool-size到 10，同时在代码里用 try-with-resources 保证连接归还。

第六条是 SSL 连接错误。现象是日志里一堆 SSL 握手警告。解决就是在连接串显式加useSSL=false。注意：本地开发关掉没问题，生产环境如果数据敏感，应该反过来打开useSSL=true并配置证书，而不是一刀切。

6. 上线前必做的自检清单：从“能跑”变成“能交”

6.1 用 EXPLAIN 验证核心查询是否走索引

很多课设系统在演示时数据量只有几十条，一切查询都快如闪电。但答辩或面试官一句话就能让你露馅：“如果这张表有十万条记录，你的查询还快吗？”提前用EXPLAIN验证查询计划是成本最低的检查。

EXPLAIN SELECT st.stu_no, st.stu_name, c.course_name, s.score FROM score s JOIN student st ON s.stu_id = st.id JOIN course c ON s.course_id = c.id WHERE s.semester = '2024-2025-1' ORDER BY s.score DESC;

看输出里的type和key两列。type是ALL代表全表扫描，说明没走索引，必须优化；range或ref是正常水平；key列显示NULL代表没用上索引。当semester字段不在任何索引里时，这条查询即使只过滤一个学期，也会把整张score表扫一遍。解决方法是给semester建普通索引：

ALTER TABLE score ADD INDEX idx_semester (semester);

6.2 给成绩数据留一份后悔药：备份与恢复命令

成绩数据最怕两件事：手动误删和建表脚本重新执行。我见过不止一次有人在测试时执行了DROP TABLE score，然后整个系统瘫痪。备份分为单表备份和全库备份。

# 全库备份 mysqldump -uroot -p score_db > /data/backup/score_db_$(date +%F).sql # 单表备份 mysqldump -uroot -p score_db score > /data/backup/score_table_$(date +%F).sql # 恢复 mysql -uroot -p score_db < /data/backup/score_db_2025-06-30.sql

mysqldump 的默认输出会包含DROP TABLE IF EXISTS语句，所以恢复时不需要手动删旧表。恢复前确认目标库名，不小心恢复到生产库的后果是灾难性的。另外备份时要加--single-transaction参数给 InnoDB 表做一致性快照，不加的话备份过程中有写入会导致备份数据逻辑不一致。

6.3 慢查询日志：用最小代价找到最慢的SQL

如果你的系统未来真正要上线给教务用，慢查询日志是你定位性能问题的眼睛。开启方式：

-- 查看当前状态 SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time'; -- 临时开启（重启后失效） SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;

long_query_time设置为 1，表示耗时超过 1 秒的查询都会被记录。这个阈值不要设成 0，否则每次查询都写日志，性能反而下降。日志文件位置用SHOW VARIABLES LIKE 'slow_query_log_file'查看。等系统跑一段时间，打开日志文件找出出现次数最多的查询语句，一般来说不是缺索引就是多表 JOIN 写法有问题。

6.4 我最后归档项目的固定习惯

我每次交付类似的 MySQL 项目时，都会在最终目录里留三个东西：init.sql（建库建表脚本加测试数据）、README.md（写明 MySQL 版本、JDBC 连接串、默认账号密码说明）、backup/目录放一份当日备份。这三个文件的价值在于，任何新环境都能在十秒内完整复现系统。这也是主从复制、读写分离这类更高阶方向的基础——没有规范的表结构脚本，后面挂任何中间件都是无源之水。

最后说一条我的教训：永远不要在生产库上直接跑没有备份的 ALTER TABLE。有一次我为了给成绩表加一个字段，直接在客户服务器上执行了ALTER TABLE score ADD COLUMN remark VARCHAR(255)，结果表被锁了几分钟，教务老师正好在录成绩，直接卡死。MySQL 8.0 的ALTER TABLE底层是建新表再切换，数据量大时耗时很长，会阻塞写入。正确做法是低峰期操作，或者用在线工具 gh-ost，这才是生产环境靠谱的姿势。希望这个项目的建表、查询、存储过程和排错经验，能帮你少走这一圈弯路。

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