简介一份基于Java和MySQL的图书馆管理信息系统设计文档面向计算机专业学生、软件开发学习者以及需要完成课程设计或毕业设计的读者适用于课程答辩、项目参考和自学入门。内容完整覆盖系统开发全流程需求分析部分梳理图书管理、读者管理、借阅服务、统计报告等功能与开发环境数据库逻辑设计讲解ER图构建、关系模型转换并给出用户信息表、图书信息表、借阅登记表的具体字段结构物理设计涉及索引创建、视图规划与安全备份机制系统实现部分介绍Java Swing/FX图形界面、JDBC数据库连接及业务逻辑编写最后还包含单元测试、集成测试、系统测试与部署上线的完整说明。资源为单个PDF文件大小644KB结构紧凑、便于查阅已有99人学习下载。读者可从中学到图书馆信息化管理系统的整体设计思路和数据库建模方法尤其适合作为毕业设计或课程设计的参考蓝本。1. 这个 PDF 标题背后是一套 Java MySQL 的最小业务系统你搜「图书馆管理信息系统(基于JAVA和MySQL).pdf」时真正想拿到的不是文档本身而是「我该怎么把图书借还这个流程用 Java 和 MySQL 落成能跑的代码」。图书馆管理信息系统的核心并不在界面多漂亮而在于三张表图书、读者、借阅记录之间的事务一致性一本书被借走时库存要减、归还时要算逾期、同一本书不能同时借给两个人。这套逻辑用 Java 做业务编排、用 MySQL 做持久化是课程设计和毕业设计里最常见的组合也是你理解 Web 后端「三层架构」最便宜的训练场。这个标题里的 PDF 只是交付文档不影响技术选型的性质JDK 8、MySQL 5.7/8.0、JDBC 或 MyBatis任选一条路都能走通。适合正在做课设的大学生也适合想快速看一遍「Java 连数据库到底连在哪一层」的转行开发者。2. 图书管理系统的分层结构为什么是 Java MySQL 而不是别的组合2.1 用 Java 做业务层、用 MySQL 做数据层的理由图书馆业务天然是「状态多、规则硬」的模型。一本图书有在馆、借出、预约、下架等状态一个读者有正常、逾期、冻结等状态这些状态转换如果只写在数据库存储过程里调试和维护成本都偏高如果完全写在 Java 代码里又会导致 SQL 里塞满重复的条件判断。常见做法是用 Java 管理业务规则用 MySQL 管理数据约束两者通过 JDBC 或 ORM 衔接。这和你的 java 基础能力直接相关需要你熟悉类、接口、异常处理以及最基础的集合操作。而 MySQL 侧只需要你掌握建表、增删改查、join 和事务这四个能力恰恰也是 mysql 面试题里最高频的四个考点。这个组合的另一层优势是资料密度大报错信息、配置样例、面试八股文几乎都能在网上找到对应案例对新手极其友好。2.2 三层架构的职责划分表在动手写代码前先把分层结构固定在脑子里。我一般会把系统拆成如下三层并在包名上严格区分层次包名职责典型类界面层view控制台菜单或 Swing 窗体只做输入输出MenuView.java业务层service校验业务规则、控制事务边界BorrowService.java数据层dao封装 JDBC 操作只处理 SQL 和结果集BookDao.java实体层entity与数据库表字段一一对应的 POJOBook.java实体层不属于三层之一它是各层之间的数据载体。初学者最容易犯的错误是把 SQL 直接写在 service 里看起来省事但当你需要把「借书」和「扣库存」放进同一个事务时没有 dao 层做统一出口事务边界会到处开花。2.3 先从 POJO 对齐数据库表开始无论你之后用纯 JDBC 还是 MyBatis实体类都要先于业务逻辑存在。以图书实体为例字段设计要和数据库表严格对应类型上注意BigDecimal对应DECIMALLocalDateTime对应DATETIMEpublic class Book { private Integer id; // 主键自增 private String isbn; // ISBN 编号 private String title; // 书名 private String author; // 作者 private Integer totalCopies; // 馆藏总数 private Integer availableCopies; // 可借数量冗余字段提升查询性能 private Integer status; // 状态1 在馆0 下架 // 无参构造、有参构造、getter/setter 省略 }这段代码的逻辑说明分成三块第一availableCopies是一个经过设计的冗余字段它不存「计算值」而是在借书时减一、还书时加一目的是一张图书列表页能直接显示可借状态不必每次都 join 借阅表做 count在图书馆管理系统这种读多写少的场景里很划算。第二status用Integer而不是String对应数据库中的TINYINT后续做条件查询时直接WHERE status 1比WHERE status 在馆性能更稳定。第三所有属性都用包装类而不是基本类型这是为了兼容数据库 NULL 值——int totalCopies在结果集为空时会直接抛空指针Integer不会。实体类写好后紧接着定义 DAO 接口让业务层面向接口编程public interface BookDao { int addBook(Book book); int updateBook(Book book); int deleteBook(Integer id); ListBook searchBooks(String keyword); Book getBookById(Integer id); }接口先行是一种约束它迫使你在写实现之前想清楚「这张表到底需要哪些操作」。新增和更新可以合并成一个save方法但拆开更直观。searchBooks返回的ListBook会用于页面展示这也是 java 集合框架最基础的应用场景。3. MySQL 表设计图书、读者、借阅记录三张核心表怎么建3.1 借阅表是关键主键策略与多对多关系图书馆管理系统最少需要三张表book图书、reader读者、borrow借阅记录。其中borrow表是核心它把「一本书被谁借走、什么时候借的、什么时候该还」这个完整过程记录下来也叫关联表。设计多对多关系时必须在中间表上额外考虑一次借阅可能包含借出日期、应还日期、实际归还日期、续借次数这四类信息它们只属于某一次借阅行为放不到图书表或读者表里去。主键策略上book和reader的主键我用自增INT但不建议只用 ISBN 做主键。原因有两点第一图书系统里同一本书可能购入多册ISBN 只能标识到书目不能标识到物理副本如果要用 ISBN 做主键你还需要引入“册”的概念复杂度立刻上升第二自有键代理主键可以避免 ISBN 录入错误导致无法修改的问题。自增 ID 是 MySQL 里最稳定的单机主键方案。3.2 三张表的建表 SQL 与字段释义下面是完整的建表语句直接在 MySQL Workbench 或命令行中执行即可。字符集统一使用utf8mb4排序规则用utf8mb4_unicode_ci这样才能正确存储和排序中文书名这也解释了为什么标题是中文系统但表结构仍然用英文名。CREATE DATABASE IF NOT EXISTS library DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE library; CREATE TABLE book ( id INT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, title VARCHAR(200) NOT NULL, author VARCHAR(100) DEFAULT , total_copies INT NOT NULL DEFAULT 1, available_copies INT NOT NULL DEFAULT 1, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 在馆0 下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_title (title), INDEX idx_available (status, available_copies) ) ENGINEInnoDB; CREATE TABLE reader ( id INT PRIMARY KEY AUTO_INCREMENT, reader_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, phone VARCHAR(20) DEFAULT , status TINYINT NOT NULL DEFAULT 1 COMMENT 1 正常0 冻结, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE borrow ( id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, reader_id INT NOT NULL, borrow_date DATETIME NOT NULL, due_date DATETIME NOT NULL, return_date DATETIME DEFAULT NULL, renew_count TINYINT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 借出中1 已归还2 逾期未还, CONSTRAINT fk_borrow_book FOREIGN KEY (book_id) REFERENCES book(id), CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES reader(id), INDEX idx_reader_status (reader_id, status), INDEX idx_due (due_date) ) ENGINEInnoDB;这段 SQL 里有几个参数值得单独说明。第一book表上的idx_available是一个联合索引它的设计依据是查询模式图书馆首页通常会展示「状态为在馆且可借数量大于 0」的图书联合索引能覆盖这个查询条件避免回表。第二borrow表的due_date上单独建索引因为逾期提醒是一个高频批处理任务每天要扫描「应还日期早于今天且未归还」的记录没有索引时全表扫描在数据量过万后就会明显变慢。第三status字段统一用TINYINT存码值而不是直接存「借出中」这样的中文这是 MySQL 表设计的基本规范具体的原因我放在下一小节展开。3.3 状态字段为什么用数字编码而不是字符串很多上手快的同学会直接写status VARCHAR(10) DEFAULT 在馆写起来直观查出来也能直接显示在界面上。但在后续开发里会出现两个实际问题一个是排序和比较的性能一个是业务变更的代价。字符串排序走的是字典序无法用索引做范围判断更麻烦的是当你需要加一个「馆际互借中」的状态时必须去所有历史数据里更新字符串而数字编码只需要在 Java 枚举里加一个值。我在字段注释里把码值和含义写明同时在前端或控制台输出时用 Java 的switch或枚举做一次映射public String getStatusText() { switch (this.status) { case 0: return 借出中; case 1: return 已归还; case 2: return 逾期未还; default: return 未知; } }这样做的好处是数据库里永远存的是紧凑的数字而界面层通过映射获得中文含义。如果你未来需要把状态位扩展为多标签也可以把TINYINT升级为VARCHAR(32)存位掩码Java 层逻辑不需要大改。这是一条从数据库到 java 基础代码都通用的设计原则持久化只存稳定的标识不存易变的展示文案。4. 用 JDBC DAO 实现借书与还书的核心流程4.1 连接参数与连接池配置三张表建好之后进入代码实现。这里有两套技术路线一套是纯 JDBC 自己管理连接另一套是 JDBC HikariCP 连接池。对于这个规模的系统我直接就上连接池哪怕课设答辩时也说得清楚连接池不是框架重装它解决的是「每次请求都重新创建物理连接导致 MySQL 连接数被打满」的问题。HikariCP 的配置写法如下先准备db.properties配置文件jdbcUrljdbc:mysql://localhost:3306/library?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue usernameroot password你的密码 driverClassNamecom.mysql.cj.jdbc.Driver maximumPoolSize10 connectionTimeout30000连接串里有几个参数必须解释清楚。useUnicodetruecharacterEncodingutf8保证中文读写不乱码这一串在 MySQL 8.0 下基本是标配serverTimezoneAsia/Shanghai解决 MySQL 驱动默认时区与本地不一致导致的DATETIME偏移 8 小时问题useSSLfalse是本地开发时的常规关闭项否则 MySQL 8.0 默认会做 SSL 握手拉长连接建立时间allowPublicKeyRetrievaltrue是 MySQL 8.0 使用caching_sha2_password认证时需要的参数不配置会报Public Key Retrieval is not allowed。4.2 用 PreparedStatement 实现图书新增顺带说清 SQL 注入原理数据访问层我坚持不拼接 SQL随时使用PreparedStatement。以addBook方法为例public int addBook(Book book) { String sql INSERT INTO book (isbn, title, author, total_copies, available_copies, status) VALUES (?, ?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, book.getIsbn()); ps.setString(2, book.getTitle()); ps.setString(3, book.getAuthor()); ps.setInt(4, book.getTotalCopies()); ps.setInt(5, book.getAvailableCopies()); ps.setInt(6, book.getStatus()); return ps.executeUpdate(); } catch (SQLException e) { e.printStackTrace(); return 0; } }这段代码的逻辑核心在PreparedStatement本身。?占位符由驱动在客户端完成参数类型的编译与转义再发送给 MySQL 服务端用户输入里的单引号、分号、注释符都会被当作普通字符串处理从根上杜绝了 OR 11这类注入。前者是三条 SQL 拼接成一条被执行后者是参数与 SQL 模板分离。mysql 面试题里这一题出现频率很高你能答出「预编译 参数化查询」六个字就能得分能补一句「服务端还会做执行计划缓存」就是加分项。这也是为什么我在 DAO 层所有 SQL 都坚持用PreparedStatement而不是Statement。4.3 借书流程的事务边界先查再写的并发一致性借书是整个系统里最容易出现并发问题的地方。常规逻辑是「先查这本书是否可借再插入借阅记录最后扣减可借数量」。如果这三个步骤之间没有事务两个读者同时点击借书两边都查到available_copies 1然后各自插入一条借阅记录可借数量变成 -1数据就坏了。正确写法是在 Service 层控制事务边界把 DAO 的连接对象下传给两个数据访问方法public boolean borrowBook(int bookId, int readerId) { String checkSql SELECT available_copies FROM book WHERE id ? AND status 1 FOR UPDATE; String insertSql INSERT INTO borrow (book_id, reader_id, borrow_date, due_date, status) VALUES (?, ?, NOW(), DATE_ADD(NOW(), INTERVAL 30 DAY), 0); String updateSql UPDATE book SET available_copies available_copies - 1 WHERE id ? AND available_copies 0; Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 关闭自动提交开启事务 PreparedStatement checkPs conn.prepareStatement(checkSql); checkPs.setInt(1, bookId); ResultSet rs checkPs.executeQuery(); if (!rs.next() || rs.getInt(1) 0) { conn.rollback(); return false; // 无可借库存直接回滚 } PreparedStatement insertPs conn.prepareStatement(insertSql); insertPs.setInt(1, bookId); insertPs.setInt(2, readerId); insertPs.executeUpdate(); PreparedStatement updatePs conn.prepareStatement(updateSql); updatePs.setInt(1, bookId); updatePs.executeUpdate(); conn.commit(); return true; } catch (SQLException e) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } return false; } finally { try { conn.setAutoCommit(true); } catch (SQLException e) { e.printStackTrace(); } DBUtil.close(conn); } }这段代码有三个关键点。第一SELECT ... FOR UPDATE是行级锁它在事务内锁住book表里id ?这一行另一个事务再执行同一条查询时会被阻塞直到当前事务提交或回滚这就解决了「查询结果在下一秒就过期」的竞态问题。第二UPDATE ... WHERE id ? AND available_copies 0是第二层兜底即使前面的行锁因为索引失效没有生效这个条件也能保证库存不会被扣成负数。第三conn.setAutoCommit(false)必须在第一个 SQL 执行之前设置很多初学者把setAutoCommit写在执行完查询之后事务根本不会开启MySQL 默认自动提交模式下每一条 SQL 都是独立事务前面锁住的行在查询结束的瞬间就被释放了。一个事务里锁行的时长直接影响系统并发量所以FOR UPDATE锁定的行数越少越好这要求WHERE条件必须命中索引否则 InnoDB 会从锁单行退化为锁表后文索引设计就是在为这里的WHERE条件服务。5. 借阅列表查询的进阶模糊查询加分页的预编译写法与中文排序勘误5.1 LIKE 模糊查询怎么和分页组合而不牺牲安全性借阅记录列表几乎必然带两个功能按书名或读者名搜索、分页展示。把这两个功能组合在一起时最容易踩的坑是「又想用PreparedStatement参数化又不知道LIKE的通配符应该放在哪里」。正确写法是在 Java 侧拼接通配符SQL 模板保持干净public ListBorrowRecord searchBorrow(String keyword, int pageNum, int pageSize) { String sql SELECT b.id, bo.title, r.name, b.borrow_date, b.due_date, b.status FROM borrow b JOIN book bo ON b.book_id bo.id JOIN reader r ON b.reader_id r.id WHERE bo.title LIKE ? OR r.name LIKE ? ORDER BY b.borrow_date DESC LIMIT ? OFFSET ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { String likePattern % keyword %; ps.setString(1, likePattern); ps.setString(2, likePattern); ps.setInt(3, pageSize); ps.setInt(4, (pageNum - 1) * pageSize); try (ResultSet rs ps.executeQuery()) { ListBorrowRecord list new ArrayList(); while (rs.next()) { BorrowRecord record new BorrowRecord(); record.setBorrowId(rs.getInt(id)); record.setBookTitle(rs.getString(title)); record.setReaderName(rs.getString(name)); record.setBorrowDate(rs.getTimestamp(borrow_date).toLocalDateTime()); record.setDueDate(rs.getTimestamp(due_date).toLocalDateTime()); record.setStatus(rs.getInt(status)); list.add(record); } return list; } } catch (SQLException e) { e.printStackTrace(); return Collections.emptyList(); } }两个容易被忽略的参数细节需要单独说明。第一LIKE ?中的?绑定的是%关键字%这个完整字符串而不是只绑定关键字本身如果把%写进 SQL 模板LIKE % ? %?占位符会被当成普通文本的一部分参数绑定直接失效。第二LIMIT ? OFFSET ?在 MySQL 8.0 里是支持绑定变量的但在 MySQL 5.7 及以下版本LIMIT子句的占位符只能绑定整型参数且OFFSET不能使用运算表达式所以(pageNum - 1) * pageSize必须在 Java 里先算好再传入。5.2 中文排序为什么不准以及ORDER BY的正确打开方式这个系统表结构里utf8mb4_unicode_ci排序规则是一个隐形的坑。utf8mb4_unicode_ci按 Unicode 码点排序中文汉字会被排到拉丁字母之后而且不同汉字之间不是按照汉语拼音排列。在查看借阅记录或图书列表时「作者」列出现乱序是正常现象不是 MySQL 排序算法的问题而是排序规则选择的问题。常见的修正是把排序规则改成utf8mb4_zh_0900_as_cs在 MySQL 8.0 中已支持中文拼音排序。但更推荐的做法是不要在数据库层解决中文排序改在 Java 内存中排序数据量在几千条这个级别时list.sort(Comparator.comparing(Book::getTitle, Collator.getInstance(Locale.CHINESE)))的耗时毫秒级内就完成而且排序逻辑与数据库解耦。当你后续把系统扩展为多语言或用 Elasticsearch 做检索引擎时这个边界会省下大量迁移成本。如果只对一列排序、查询结果集在千条以内优先考虑 Java 侧排序把ORDER BY从 SQL 里拿掉让 MySQL 专注于过滤和分页。本文还有配套的精品资源点击获取
基于Java和MySQL的图书馆管理系统设计与实现
简介一份基于Java和MySQL的图书馆管理信息系统设计文档面向计算机专业学生、软件开发学习者以及需要完成课程设计或毕业设计的读者适用于课程答辩、项目参考和自学入门。内容完整覆盖系统开发全流程需求分析部分梳理图书管理、读者管理、借阅服务、统计报告等功能与开发环境数据库逻辑设计讲解ER图构建、关系模型转换并给出用户信息表、图书信息表、借阅登记表的具体字段结构物理设计涉及索引创建、视图规划与安全备份机制系统实现部分介绍Java Swing/FX图形界面、JDBC数据库连接及业务逻辑编写最后还包含单元测试、集成测试、系统测试与部署上线的完整说明。资源为单个PDF文件大小644KB结构紧凑、便于查阅已有99人学习下载。读者可从中学到图书馆信息化管理系统的整体设计思路和数据库建模方法尤其适合作为毕业设计或课程设计的参考蓝本。1. 这个 PDF 标题背后是一套 Java MySQL 的最小业务系统你搜「图书馆管理信息系统(基于JAVA和MySQL).pdf」时真正想拿到的不是文档本身而是「我该怎么把图书借还这个流程用 Java 和 MySQL 落成能跑的代码」。图书馆管理信息系统的核心并不在界面多漂亮而在于三张表图书、读者、借阅记录之间的事务一致性一本书被借走时库存要减、归还时要算逾期、同一本书不能同时借给两个人。这套逻辑用 Java 做业务编排、用 MySQL 做持久化是课程设计和毕业设计里最常见的组合也是你理解 Web 后端「三层架构」最便宜的训练场。这个标题里的 PDF 只是交付文档不影响技术选型的性质JDK 8、MySQL 5.7/8.0、JDBC 或 MyBatis任选一条路都能走通。适合正在做课设的大学生也适合想快速看一遍「Java 连数据库到底连在哪一层」的转行开发者。2. 图书管理系统的分层结构为什么是 Java MySQL 而不是别的组合2.1 用 Java 做业务层、用 MySQL 做数据层的理由图书馆业务天然是「状态多、规则硬」的模型。一本图书有在馆、借出、预约、下架等状态一个读者有正常、逾期、冻结等状态这些状态转换如果只写在数据库存储过程里调试和维护成本都偏高如果完全写在 Java 代码里又会导致 SQL 里塞满重复的条件判断。常见做法是用 Java 管理业务规则用 MySQL 管理数据约束两者通过 JDBC 或 ORM 衔接。这和你的 java 基础能力直接相关需要你熟悉类、接口、异常处理以及最基础的集合操作。而 MySQL 侧只需要你掌握建表、增删改查、join 和事务这四个能力恰恰也是 mysql 面试题里最高频的四个考点。这个组合的另一层优势是资料密度大报错信息、配置样例、面试八股文几乎都能在网上找到对应案例对新手极其友好。2.2 三层架构的职责划分表在动手写代码前先把分层结构固定在脑子里。我一般会把系统拆成如下三层并在包名上严格区分层次包名职责典型类界面层view控制台菜单或 Swing 窗体只做输入输出MenuView.java业务层service校验业务规则、控制事务边界BorrowService.java数据层dao封装 JDBC 操作只处理 SQL 和结果集BookDao.java实体层entity与数据库表字段一一对应的 POJOBook.java实体层不属于三层之一它是各层之间的数据载体。初学者最容易犯的错误是把 SQL 直接写在 service 里看起来省事但当你需要把「借书」和「扣库存」放进同一个事务时没有 dao 层做统一出口事务边界会到处开花。2.3 先从 POJO 对齐数据库表开始无论你之后用纯 JDBC 还是 MyBatis实体类都要先于业务逻辑存在。以图书实体为例字段设计要和数据库表严格对应类型上注意BigDecimal对应DECIMALLocalDateTime对应DATETIMEpublic class Book { private Integer id; // 主键自增 private String isbn; // ISBN 编号 private String title; // 书名 private String author; // 作者 private Integer totalCopies; // 馆藏总数 private Integer availableCopies; // 可借数量冗余字段提升查询性能 private Integer status; // 状态1 在馆0 下架 // 无参构造、有参构造、getter/setter 省略 }这段代码的逻辑说明分成三块第一availableCopies是一个经过设计的冗余字段它不存「计算值」而是在借书时减一、还书时加一目的是一张图书列表页能直接显示可借状态不必每次都 join 借阅表做 count在图书馆管理系统这种读多写少的场景里很划算。第二status用Integer而不是String对应数据库中的TINYINT后续做条件查询时直接WHERE status 1比WHERE status 在馆性能更稳定。第三所有属性都用包装类而不是基本类型这是为了兼容数据库 NULL 值——int totalCopies在结果集为空时会直接抛空指针Integer不会。实体类写好后紧接着定义 DAO 接口让业务层面向接口编程public interface BookDao { int addBook(Book book); int updateBook(Book book); int deleteBook(Integer id); ListBook searchBooks(String keyword); Book getBookById(Integer id); }接口先行是一种约束它迫使你在写实现之前想清楚「这张表到底需要哪些操作」。新增和更新可以合并成一个save方法但拆开更直观。searchBooks返回的ListBook会用于页面展示这也是 java 集合框架最基础的应用场景。3. MySQL 表设计图书、读者、借阅记录三张核心表怎么建3.1 借阅表是关键主键策略与多对多关系图书馆管理系统最少需要三张表book图书、reader读者、borrow借阅记录。其中borrow表是核心它把「一本书被谁借走、什么时候借的、什么时候该还」这个完整过程记录下来也叫关联表。设计多对多关系时必须在中间表上额外考虑一次借阅可能包含借出日期、应还日期、实际归还日期、续借次数这四类信息它们只属于某一次借阅行为放不到图书表或读者表里去。主键策略上book和reader的主键我用自增INT但不建议只用 ISBN 做主键。原因有两点第一图书系统里同一本书可能购入多册ISBN 只能标识到书目不能标识到物理副本如果要用 ISBN 做主键你还需要引入“册”的概念复杂度立刻上升第二自有键代理主键可以避免 ISBN 录入错误导致无法修改的问题。自增 ID 是 MySQL 里最稳定的单机主键方案。3.2 三张表的建表 SQL 与字段释义下面是完整的建表语句直接在 MySQL Workbench 或命令行中执行即可。字符集统一使用utf8mb4排序规则用utf8mb4_unicode_ci这样才能正确存储和排序中文书名这也解释了为什么标题是中文系统但表结构仍然用英文名。CREATE DATABASE IF NOT EXISTS library DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE library; CREATE TABLE book ( id INT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, title VARCHAR(200) NOT NULL, author VARCHAR(100) DEFAULT , total_copies INT NOT NULL DEFAULT 1, available_copies INT NOT NULL DEFAULT 1, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 在馆0 下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_title (title), INDEX idx_available (status, available_copies) ) ENGINEInnoDB; CREATE TABLE reader ( id INT PRIMARY KEY AUTO_INCREMENT, reader_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, phone VARCHAR(20) DEFAULT , status TINYINT NOT NULL DEFAULT 1 COMMENT 1 正常0 冻结, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE borrow ( id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, reader_id INT NOT NULL, borrow_date DATETIME NOT NULL, due_date DATETIME NOT NULL, return_date DATETIME DEFAULT NULL, renew_count TINYINT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 借出中1 已归还2 逾期未还, CONSTRAINT fk_borrow_book FOREIGN KEY (book_id) REFERENCES book(id), CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES reader(id), INDEX idx_reader_status (reader_id, status), INDEX idx_due (due_date) ) ENGINEInnoDB;这段 SQL 里有几个参数值得单独说明。第一book表上的idx_available是一个联合索引它的设计依据是查询模式图书馆首页通常会展示「状态为在馆且可借数量大于 0」的图书联合索引能覆盖这个查询条件避免回表。第二borrow表的due_date上单独建索引因为逾期提醒是一个高频批处理任务每天要扫描「应还日期早于今天且未归还」的记录没有索引时全表扫描在数据量过万后就会明显变慢。第三status字段统一用TINYINT存码值而不是直接存「借出中」这样的中文这是 MySQL 表设计的基本规范具体的原因我放在下一小节展开。3.3 状态字段为什么用数字编码而不是字符串很多上手快的同学会直接写status VARCHAR(10) DEFAULT 在馆写起来直观查出来也能直接显示在界面上。但在后续开发里会出现两个实际问题一个是排序和比较的性能一个是业务变更的代价。字符串排序走的是字典序无法用索引做范围判断更麻烦的是当你需要加一个「馆际互借中」的状态时必须去所有历史数据里更新字符串而数字编码只需要在 Java 枚举里加一个值。我在字段注释里把码值和含义写明同时在前端或控制台输出时用 Java 的switch或枚举做一次映射public String getStatusText() { switch (this.status) { case 0: return 借出中; case 1: return 已归还; case 2: return 逾期未还; default: return 未知; } }这样做的好处是数据库里永远存的是紧凑的数字而界面层通过映射获得中文含义。如果你未来需要把状态位扩展为多标签也可以把TINYINT升级为VARCHAR(32)存位掩码Java 层逻辑不需要大改。这是一条从数据库到 java 基础代码都通用的设计原则持久化只存稳定的标识不存易变的展示文案。4. 用 JDBC DAO 实现借书与还书的核心流程4.1 连接参数与连接池配置三张表建好之后进入代码实现。这里有两套技术路线一套是纯 JDBC 自己管理连接另一套是 JDBC HikariCP 连接池。对于这个规模的系统我直接就上连接池哪怕课设答辩时也说得清楚连接池不是框架重装它解决的是「每次请求都重新创建物理连接导致 MySQL 连接数被打满」的问题。HikariCP 的配置写法如下先准备db.properties配置文件jdbcUrljdbc:mysql://localhost:3306/library?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue usernameroot password你的密码 driverClassNamecom.mysql.cj.jdbc.Driver maximumPoolSize10 connectionTimeout30000连接串里有几个参数必须解释清楚。useUnicodetruecharacterEncodingutf8保证中文读写不乱码这一串在 MySQL 8.0 下基本是标配serverTimezoneAsia/Shanghai解决 MySQL 驱动默认时区与本地不一致导致的DATETIME偏移 8 小时问题useSSLfalse是本地开发时的常规关闭项否则 MySQL 8.0 默认会做 SSL 握手拉长连接建立时间allowPublicKeyRetrievaltrue是 MySQL 8.0 使用caching_sha2_password认证时需要的参数不配置会报Public Key Retrieval is not allowed。4.2 用 PreparedStatement 实现图书新增顺带说清 SQL 注入原理数据访问层我坚持不拼接 SQL随时使用PreparedStatement。以addBook方法为例public int addBook(Book book) { String sql INSERT INTO book (isbn, title, author, total_copies, available_copies, status) VALUES (?, ?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, book.getIsbn()); ps.setString(2, book.getTitle()); ps.setString(3, book.getAuthor()); ps.setInt(4, book.getTotalCopies()); ps.setInt(5, book.getAvailableCopies()); ps.setInt(6, book.getStatus()); return ps.executeUpdate(); } catch (SQLException e) { e.printStackTrace(); return 0; } }这段代码的逻辑核心在PreparedStatement本身。?占位符由驱动在客户端完成参数类型的编译与转义再发送给 MySQL 服务端用户输入里的单引号、分号、注释符都会被当作普通字符串处理从根上杜绝了 OR 11这类注入。前者是三条 SQL 拼接成一条被执行后者是参数与 SQL 模板分离。mysql 面试题里这一题出现频率很高你能答出「预编译 参数化查询」六个字就能得分能补一句「服务端还会做执行计划缓存」就是加分项。这也是为什么我在 DAO 层所有 SQL 都坚持用PreparedStatement而不是Statement。4.3 借书流程的事务边界先查再写的并发一致性借书是整个系统里最容易出现并发问题的地方。常规逻辑是「先查这本书是否可借再插入借阅记录最后扣减可借数量」。如果这三个步骤之间没有事务两个读者同时点击借书两边都查到available_copies 1然后各自插入一条借阅记录可借数量变成 -1数据就坏了。正确写法是在 Service 层控制事务边界把 DAO 的连接对象下传给两个数据访问方法public boolean borrowBook(int bookId, int readerId) { String checkSql SELECT available_copies FROM book WHERE id ? AND status 1 FOR UPDATE; String insertSql INSERT INTO borrow (book_id, reader_id, borrow_date, due_date, status) VALUES (?, ?, NOW(), DATE_ADD(NOW(), INTERVAL 30 DAY), 0); String updateSql UPDATE book SET available_copies available_copies - 1 WHERE id ? AND available_copies 0; Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 关闭自动提交开启事务 PreparedStatement checkPs conn.prepareStatement(checkSql); checkPs.setInt(1, bookId); ResultSet rs checkPs.executeQuery(); if (!rs.next() || rs.getInt(1) 0) { conn.rollback(); return false; // 无可借库存直接回滚 } PreparedStatement insertPs conn.prepareStatement(insertSql); insertPs.setInt(1, bookId); insertPs.setInt(2, readerId); insertPs.executeUpdate(); PreparedStatement updatePs conn.prepareStatement(updateSql); updatePs.setInt(1, bookId); updatePs.executeUpdate(); conn.commit(); return true; } catch (SQLException e) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } return false; } finally { try { conn.setAutoCommit(true); } catch (SQLException e) { e.printStackTrace(); } DBUtil.close(conn); } }这段代码有三个关键点。第一SELECT ... FOR UPDATE是行级锁它在事务内锁住book表里id ?这一行另一个事务再执行同一条查询时会被阻塞直到当前事务提交或回滚这就解决了「查询结果在下一秒就过期」的竞态问题。第二UPDATE ... WHERE id ? AND available_copies 0是第二层兜底即使前面的行锁因为索引失效没有生效这个条件也能保证库存不会被扣成负数。第三conn.setAutoCommit(false)必须在第一个 SQL 执行之前设置很多初学者把setAutoCommit写在执行完查询之后事务根本不会开启MySQL 默认自动提交模式下每一条 SQL 都是独立事务前面锁住的行在查询结束的瞬间就被释放了。一个事务里锁行的时长直接影响系统并发量所以FOR UPDATE锁定的行数越少越好这要求WHERE条件必须命中索引否则 InnoDB 会从锁单行退化为锁表后文索引设计就是在为这里的WHERE条件服务。5. 借阅列表查询的进阶模糊查询加分页的预编译写法与中文排序勘误5.1 LIKE 模糊查询怎么和分页组合而不牺牲安全性借阅记录列表几乎必然带两个功能按书名或读者名搜索、分页展示。把这两个功能组合在一起时最容易踩的坑是「又想用PreparedStatement参数化又不知道LIKE的通配符应该放在哪里」。正确写法是在 Java 侧拼接通配符SQL 模板保持干净public ListBorrowRecord searchBorrow(String keyword, int pageNum, int pageSize) { String sql SELECT b.id, bo.title, r.name, b.borrow_date, b.due_date, b.status FROM borrow b JOIN book bo ON b.book_id bo.id JOIN reader r ON b.reader_id r.id WHERE bo.title LIKE ? OR r.name LIKE ? ORDER BY b.borrow_date DESC LIMIT ? OFFSET ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { String likePattern % keyword %; ps.setString(1, likePattern); ps.setString(2, likePattern); ps.setInt(3, pageSize); ps.setInt(4, (pageNum - 1) * pageSize); try (ResultSet rs ps.executeQuery()) { ListBorrowRecord list new ArrayList(); while (rs.next()) { BorrowRecord record new BorrowRecord(); record.setBorrowId(rs.getInt(id)); record.setBookTitle(rs.getString(title)); record.setReaderName(rs.getString(name)); record.setBorrowDate(rs.getTimestamp(borrow_date).toLocalDateTime()); record.setDueDate(rs.getTimestamp(due_date).toLocalDateTime()); record.setStatus(rs.getInt(status)); list.add(record); } return list; } } catch (SQLException e) { e.printStackTrace(); return Collections.emptyList(); } }两个容易被忽略的参数细节需要单独说明。第一LIKE ?中的?绑定的是%关键字%这个完整字符串而不是只绑定关键字本身如果把%写进 SQL 模板LIKE % ? %?占位符会被当成普通文本的一部分参数绑定直接失效。第二LIMIT ? OFFSET ?在 MySQL 8.0 里是支持绑定变量的但在 MySQL 5.7 及以下版本LIMIT子句的占位符只能绑定整型参数且OFFSET不能使用运算表达式所以(pageNum - 1) * pageSize必须在 Java 里先算好再传入。5.2 中文排序为什么不准以及ORDER BY的正确打开方式这个系统表结构里utf8mb4_unicode_ci排序规则是一个隐形的坑。utf8mb4_unicode_ci按 Unicode 码点排序中文汉字会被排到拉丁字母之后而且不同汉字之间不是按照汉语拼音排列。在查看借阅记录或图书列表时「作者」列出现乱序是正常现象不是 MySQL 排序算法的问题而是排序规则选择的问题。常见的修正是把排序规则改成utf8mb4_zh_0900_as_cs在 MySQL 8.0 中已支持中文拼音排序。但更推荐的做法是不要在数据库层解决中文排序改在 Java 内存中排序数据量在几千条这个级别时list.sort(Comparator.comparing(Book::getTitle, Collator.getInstance(Locale.CHINESE)))的耗时毫秒级内就完成而且排序逻辑与数据库解耦。当你后续把系统扩展为多语言或用 Elasticsearch 做检索引擎时这个边界会省下大量迁移成本。如果只对一列排序、查询结果集在千条以内优先考虑 Java 侧排序把ORDER BY从 SQL 里拿掉让 MySQL 专注于过滤和分页。本文还有配套的精品资源点击获取
