企业官网建设流程全解析

简介：学校图书借阅管理系统的数据库设计文档，是一份面向数据库系统设计课程的完整课程设计报告，适合计算机相关专业学生和需要开发小型图书管理系统的学习者参考。压缩包共1个Word文档，大小4.16MB，报告内包含数据字典、数据流图、结构图、E-R图，以及读者/管理员登录、图书信息录入与修改、读者注册与信息维护、图书查询借阅、数据备份恢复、系统管理等模块的功能说明和主要程序代码。这份报告围绕图书馆借阅场景，梳理了从权限控制到数据安全的系统实现思路，可帮助读者快速掌握数据库系统设计的整体流程，并能直接用于课程设计报告撰写、数据库表结构设计或系统功能扩展。目前已有11178人学习，实用价值较高，是数据库课程设计的优质参考资料。

1. 图书借阅管理系统数据库设计：为什么说表结构先于代码决定系统生死

学校图书借阅管理系统听起来不过是「学生借书、老师还书」的小工具，但真正把数据库设计走上线，你会发现最难的不是写接口，而是把「一本热门书被 50 个人同时预约、有人逾期不还、馆藏盘点对不上账」这些业务现实塞进关系模型里。我见过太多项目卡在路由层、卡在登录鉴权，最后都绕回同一个问题：借阅记录表该不该冗余书籍状态？学生表要不要存班级名称？这些决策在系统上线三个月后变成运维噩梦。本文就按这个顺序拆开讲：先立实体关系，再给可复现的建表 SQL，然后用借还事务和索引设计把查询性能讲透，最后集中说 5 个常见坑和 Spring Boot 集成时的细节。数据库系统设计不是画一张 ER 图就完事，它是一套能扛住开学季并发借书的落地方案。读完这份设计笔记，你最少能直接拷走一套核心表 DDL，并且知道每张表为什么长这样、哪些字段是刻意为之。

2. 从业务规则到关系模型：借阅系统先要回答的实体与关系问题

设计数据库的第一步永远是问业务，而不是打开 Navicat 建表。图书借阅管理系统表面是「谁在什么时间借了哪本书」，但真正落表前要把这条主链路拆成四个角色：读者、馆藏、借阅行为、图书目录。下面分别把这些角色映射成关系模型里的实体，并讨论每个实体上最容易遗漏的字段和关系。

2.1 先盘点业务单据：读者、馆藏与借阅行为如何变成表

我一般会把借阅业务拆成三张强实体表加若干字典表。强实体是student（读者）、book（书目）、copy（馆藏副本），外加一张borrow_record（借阅流水）。很多新手只建book不建copy，直接把「书库里有没有这本书」和「这本书有多少本可借」混在一张表里，这是设计课上讲过、但实战里反复出现的错误。

为什么要单独建copy？因为同一本《数据库系统概论》可能有 20 本副本，每本有独立的条形码、损坏状态、当前借出状态。如果把状态挂在book表上，20 本副本的状态没法独立记录，归还时也无法定位到具体某一本。正确做法是book只存书目信息（ISBN、书名、作者、出版社、分类号），copy表存每一本物理书的馆藏信息，借阅流水则同时引用读者 ID 和副本 ID。

三张实体表的关系是：一个读者可以借多本副本，一个副本只能被一个读者借出，所以student和copy之间是多对多，而borrow_record就是它们的关联实体。关联实体除了外键，还要带上借出时间、应还时间、实际归还时间、续借次数、状态等描述自身行为的属性。

2.2 三范式与反范式之间的取舍：冗余字段该不该加

数据库设计教科书强调第三范式：非主属性不传递依赖、不部分依赖。但在借阅系统里，严格三范式会产生一些让查询很难受的表结构。比如borrow_record只存copy_id，查询「张三现在借了哪些书」必须 joincopy再 joinbook才能拿到书名，列表页一次要连三张表。

一个折中方案是在borrow_record里冗余book_name、book_isbn这两个字段。它们确实违反第三范式，但换来的是借阅列表页和逾期提醒页少两次 join。我一般只在「读多写少」的表上做这种冗余，借阅流水恰好符合这个特征：一条记录创建后内容基本不变，冗余的书名在图书信息改名时可能需要同步，但这种同步可以放到图书维护功能里去触发，不用靠数据库来保证。

另一个常见的冗余设计是student表存class_name。严格做法是拆class实体再关联，但对中小学或院系规模不大的学校，班级名称几乎不变化，冗余下来能让借阅排行榜和学生信息列表省掉一次 join。如果你要做的系统规模大到班级可能频繁调整，那再拆不迟。

2.3 字典表的设计：分类、出版社、操作员该独立还是该写死

分类树和出版社不建议写死在代码枚举里，而应建字典表。图书分类在图书馆业务里有自己的标准（中图法分类号），例如TP311.13代表数据库理论。如果你把分类直接写成book表上一个 varchar 字段，后续做分类统计和按分类树浏览馆藏时会非常被动。建议建category表，字段包括分类号、分类名称、父分类号、排序号，book表用category_id外键关联。

出版社相对简单，可以建publisher表存出版社名称和简称，book表关联其主键。这样做的好处是统计某个出版社的藏书量时不用对冗余字符串做 LIKE 匹配，而且出版社会改名或合并，字典表里好维护。操作员/管理员账号如果是系统内置角色，直接建admin表就行；如果要对接学校统一认证，那就预留union_id字段，方便以后改造。

3. 建库建表：一套可直接落地的 DDL 与字段设计

关系模型画好后，下一步就是落成 SQL。这里的每个决定都有它的理由，包括字符集、引擎、时间类型、主键策略和约束设置。下面给出核心表的完整建表语句，每段 DDL 后面跟着说明参数怎么选、不这么设会踩什么坑。

3.1 字符集、引擎与时间类型：建库前的三个前置决定

如果你用 MySQL 8.0，建库字符集直接选utf8mb4，排序规则选utf8mb4_0900_ai_ci。如果你的环境还是 MySQL 5.7，排序规则用utf8mb4_general_ci。字符集不要省成utf8，因为 MySQL 的utf8是utf8mb3，它存不了 emoji 和部分生僻字。学生姓名里万一有这种字符，入库就直接报错或被截断，这类问题现象很隐蔽，数据量大之后很难排查。

引擎选 InnoDB，这是事务和行级锁的前提。借还书操作涉及库存扣减和流水写入，必须在一个事务里完成，MyISAM 没有事务支持，在这个场景下没有讨论必要。时间类型我建议日期型字段用DATE，日期时间型用DATETIME。TIMESTAMP虽然省空间但有 2038 年问题，而且受时区影响，去留由业务定夺，你不好控制应用服务器的时区配置。另外一个习惯是每张表都加create_time和update_time两个DATETIME字段，并让update_time在应用层更新，不依赖数据库的 ON UPDATE 语法，因为框架层做乐观锁时要自己控制这个值。

CREATE DATABASE IF NOT EXISTS library_system DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci;

这个建库语句的参数要点在于DEFAULT CHARACTER SET和DEFAULT COLLATE都显式指定。如果你省略 COLLATE，MySQL 会用字符集的默认排序规则，不同版本默认值不一致，后续做表间关联查询时会出现排序规则冲突报错。同理，建每张表时也不要依赖库级默认值，表里同样写清楚。

3.2 核心表的 DDL：student、book、copy、borrow_record 怎么建

下面这四张表构成了系统的骨架。代码里我刻意把约束、默认值和注释都写全，方便你直接在自己的环境里执行。

student表：

CREATE TABLE `student` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '读者ID', `student_no` VARCHAR(20) NOT NULL COMMENT '学号/工号', `name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT NOT NULL DEFAULT 0 COMMENT '性别 0-未知 1-男 2-女', `class_name` VARCHAR(100) DEFAULT NULL COMMENT '班级名称（冗余）', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1-正常 0-禁用', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='读者表';

student_no必须建唯一索引。学号是业务上的自然键，虽然我们习惯用自增id做主键，但业务上不允许出现两个相同学号。这里的class_name就是上一节说的反范式冗余字段，读者管理页面直接展示班级，不用去 join 班级表。status字段用来做停用/注销，比如学生毕业或转学后置为 0，保留历史借阅记录但禁止新借书。

book表：

CREATE TABLE `book` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '书目ID', `isbn` VARCHAR(20) NOT NULL COMMENT 'ISBN号', `title` VARCHAR(200) NOT NULL COMMENT '书名', `author` VARCHAR(100) DEFAULT NULL COMMENT '作者', `publisher_id` BIGINT DEFAULT NULL COMMENT '出版社ID', `category_id` BIGINT DEFAULT NULL COMMENT '分类ID', `price` DECIMAL(10,2) DEFAULT NULL COMMENT '定价', `total_copies` INT NOT NULL DEFAULT 0 COMMENT '馆藏总量（冗余）', `available_copies` INT NOT NULL DEFAULT 0 COMMENT '可借数量（冗余）', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_book_title` (`title`), KEY `idx_book_isbn` (`isbn`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='书目表';

total_copies和available_copies是我有意加的冗余。严格设计下，馆藏总数可以从copy表 COUNT 出来，可借数量也可以从copy表 status 统计出来。但图书列表页最常用的就是「这本书还有没有得借」，如果不冗余这两个字段，每次列表都要做一次聚合查询，数据量上来以后这是不必要的压力。代价是每次入库、借出、归还都要同步维护这两个数字，落在事务里一起做。这就是用「更新时的成本」换「查询时的性能」。

copy表：

CREATE TABLE `copy` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '副本ID', `book_id` BIGINT NOT NULL COMMENT '所属书目ID', `barcode` VARCHAR(50) NOT NULL COMMENT '馆藏条形码', `location` VARCHAR(100) DEFAULT NULL COMMENT '馆藏位置', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1-在馆 2-借出 3-破损 4-下架', `borrow_count` INT NOT NULL DEFAULT 0 COMMENT '累计借出次数', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_barcode` (`barcode`), KEY `idx_copy_book` (`book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='馆藏副本表';

注意copy和book是主从关系，copy.book_id外键指向book.id。这里不用CHECK约束限制 status 的取值范围，因为 MySQL 8.0.16 之前的版本不强制 CHECK 约束，统一用应用层校验更省心。borrow_count用于图书热度统计，每借出一本就让它的值 +1，统计热门图书时直接按这个字段排序，不用去 count 流水表。

borrow_record表是整张设计里最重要的关联实体：

CREATE TABLE `borrow_record` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '流水ID', `student_id` BIGINT NOT NULL COMMENT '读者ID', `copy_id` BIGINT NOT NULL COMMENT '副本ID', `book_id` BIGINT NOT NULL COMMENT '书目ID（冗余）', `book_title` VARCHAR(200) NOT NULL COMMENT '书名（冗余）', `borrow_time` DATETIME NOT NULL COMMENT '借出时间', `due_time` DATETIME NOT NULL COMMENT '应还时间', `return_time` DATETIME DEFAULT NULL COMMENT '实际归还时间', `renew_count` TINYINT NOT NULL DEFAULT 0 COMMENT '续借次数', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1-借出中 2-已归还 3-逾期未还 4-丢失', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_record_student_time` (`student_id`, `borrow_time`), KEY `idx_record_copy_id` (`copy_id`), KEY `idx_record_status_due` (`status`, `due_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='借阅流水表';

把book_id和book_title冗余在流水表里，是为了查询「某读者借过什么书」时直接命中流水表，不用 join 书目表。这个取舍在一开始就说明了理由。三个索引分别服务三类查询：按读者查借阅历史、按副本查当前状态、按状态和到期时间查逾期列表。注意idx_record_student_time把student_id放前面，因为查某个学生的借阅记录是最高频操作，把等值条件字段放在联合索引最左侧才能让索引生效。

3.3 约束与外键：借阅关系哪端不能放任不管

外键约束的问题在实战圈里争论很大。我的做法是：表结构设计时保留外键语义，但在建表语句里不写FOREIGN KEY，由应用层保证引用完整性。原因有两条：一是 InnoDB 的外键检查在批量导入和分库分表时会变成阻碍；二是如果误删了被引用的父表记录，外键的级联动作可能把借阅历史连带删掉，这在本系统里是灾难。删除和更新操作都通过应用层先做校验，再执行 SQL，可控制性更强。读者表被借阅记录引用时，我们不再允许物理删除读者，只允许置status = 0禁用，就是出于这个考虑。

但约束不能完全没有，至少以下几种要做：student_no和barcode的唯一约束、必填字段的NOT NULL、借贷时间的默认值和状态字段的默认值。外键不建不代表关系丢了，设计文档里要把外键关系画出来，代码里通过联合查询来维护。

4. 借阅与归还的 SQL 实务：事务、并发和状态流转

表建好之后，真正的挑战在借书、还书的事务处理上。这一章讨论核心的 SQL 怎么写才是安全的，包括库存扣减的原子性、归还时状态机的流转，以及支撑这些查询的索引设计。很多系统上线后出现「书借出去了但库存没减」「同一本书同时被两个人借走」，问题都出在这一层的 SQL 设计不严谨。

4.1 一次借书的原子操作：库存扣减与流水写入

借书涉及三个数据变化：插入一条借阅流水、把对应copy状态改为借出、把book.available_copies减 1。这三个操作必须在一个事务里完成。你可能会想先查available_copies是否大于 0，再决定能不能借。但在并发环境下，两个请求同时读到available_copies = 1，然后都去执行更新，就会出现超借。

正确的写法是用UPDATE ... WHERE available_copies > 0做条件更新，让数据库的行锁来保证「扣减」这个动作的原子性。下面是一段完整的借书事务：

START TRANSACTION; -- 1. 扣减书目可借数量，只有可借数大于 0 才允许更新，影响行数为 0 则说明书已借完 UPDATE `book` SET `available_copies` = `available_copies` - 1, `update_time` = NOW() WHERE `id` = 1 AND `available_copies` > 0; -- 2. 检查上一步影响的行数，若为 0 则 ROLLBACK 并提示用户 -- 这一步在应用层判断 ROW_COUNT() 或由 DAO 返回受影响的记录数 -- 3. 借出一本副本，把状态从 1（在馆）改为 2（借出） UPDATE `copy` SET `status` = 2, `borrow_count` = `borrow_count` + 1, `update_time` = NOW() WHERE `id` = 100 AND `status` = 1; -- 4. 插入借阅流水，应还时间按当前时间加 30 天 INSERT INTO `borrow_record` (`student_id`, `copy_id`, `book_id`, `book_title`, `borrow_time`, `due_time`, `status`) VALUES (2024001, 100, 1, '数据库系统概论', NOW(), DATE_ADD(NOW(), INTERVAL 30 DAY), 1); COMMIT;

这段 SQL 的关键在第一步的AND available_copies > 0和第三步的AND status = 1。两个条件更新都会在命中的行上加排他锁，并发请求只能有一个走到COMMIT，另一个在执行第一步时被阻塞，等前一个事务提交后，它再去更新时条件已经不成立，影响行数为 0，应用层直接返回「库存不足」或「该副本不在馆」。这才是并发安全的借书逻辑，而不是先用 SELECT 判断再 UPDATE。

执行到这里有一个容易忽略的细节：copy_id = 100和book_id = 1之间的归属关系，应当在事务里先验证copy.book_id = book.id，否则可能出现「把 A 书的副本当成 B 书的副本借出去」的数据错误。我的习惯是先SELECT book_id FROM copy WHERE id = 100 FOR UPDATE，在应用层比对后再执行上面的 UPDATE，这样程序和运维人员在排查问题时都有据可查。

4.2 归还、续借与逾期：状态机在 SQL 里怎么落

还书的操作与借书对称：更新流水状态、把副本状态改回在馆、把书目的可借数量加回去。归还的 SQL 没有并发问题，因为一本被借出的书在同一时间只有一个借阅人。但归还动作里最容易漏的是逾期标记：如果归还时当前时间晚于due_time，说明产生了逾期，需要在业务上产生一条违约记录或罚金记录。

START TRANSACTION; -- 1. 更新借阅流水为已归还，同时指定实际的归还时间 UPDATE `borrow_record` SET `status` = 2, `return_time` = NOW(), `update_time` = NOW() WHERE `id` = 500 AND `status` = 1; -- 2. 把对应副本改回在馆 UPDATE `copy` SET `status` = 1, `update_time` = NOW() WHERE `id` = 100 AND `status` = 2; -- 3. 把书目可借数加回 1 UPDATE `book` SET `available_copies` = `available_copies` + 1, `update_time` = NOW() WHERE `id` = 1; COMMIT;

归还的状态校验在应用层做：先查出流水，比对return_time IS NOT NULL和status是否等于 1，如果这条记录已经归还过，直接提示「重复归还」并禁止继续执行。这一步不加数据库约束也能工作，但你会发现测试时重复点击还书按钮很容易触发这问题，所以应用层的状态校验是必须的。

续借的本质是把due_time往后推，同时renew_count加一。业务规则通常限制续借次数不超过 2 次，且不能在有逾期记录的情况下续借。这个逻辑用一条 UPDATE 就能完成条件判断：

UPDATE `borrow_record` SET `due_time` = DATE_ADD(`due_time`, INTERVAL 30 DAY), `renew_count` = `renew_count` + 1, `update_time` = NOW() WHERE `id` = 500 AND `status` = 1 AND `renew_count` < 2 AND `due_time` > NOW();

due_time > NOW()的存在是为了阻止对已逾期记录做续借。影响行数为 0 时，应用层需要再查一次记录，区分到底是「超了续借次数」还是「已经逾期」还是「状态不对」，然后给出不同的提示。这种条件 UPDATE 的写法比先 SELECT 再 UPDATE 少一次交互，也更难出现竞态问题。

4.3 索引设计：哪些查询必须走索引才能撑住

在这个系统里，最高频的查询是「某学生当前借了哪些书」「某本书有哪些副本」「逾期列表」。对应到上一节的索引设计，分别是idx_record_student_time的等值前缀、idx_copy_book、idx_record_status_due。如果你不做这些索引，MySQL 会走全表扫，在开学季借阅量达到几万条时，页面响应时间会从毫秒级掉到秒级，并且拖垮整个库的并发能力。

一个常见误用是给每列单独建索引。例如borrow_record表上有student_id索引、status索引、due_time索引，但查询条件是status = 1 AND due_time < NOW()时，MySQL 的优化器通常只能用到其中一个索引，另一个条件靠回表过滤。正确做法是建联合索引(status, due_time)，让两个条件都走索引。反过来如果student_id是等值条件，borrow_time是范围条件，那联合索引(student_id, borrow_time)中的borrow_time只能支持到第一个范围条件，再往后加列意义不大。联合索引的列顺序，要按「等值条件在前、范围条件在后」的原则安排。

book表的书名查询应该用前缀索引还是普通索引？title是变长字符串，如果直接建普通索引，200 个字符的长度会让索引页占用很大空间。我的习惯是把title索引改成前缀索引，例如KEY idx_book_title (title(50))，查询时WHERE title LIKE '数据库%'走这个索引。但注意LIKE '%数据库%'这种中间匹配仍然全表扫，这属于业务上允许的搜索范围，真要支持全文检索得另上全文索引或 Elasticsearch，不在本文讨论范围内。对于学校这种规模，前缀索引加应用层搜索足够用。

5. 图书借阅系统数据库设计避坑指南：5 个必须提前规避的运行期问题

设计文档里永远发现不了的问题，要到数据量上来才浮出水面。这一章把我经历过的和看过别人经历过的运行时问题集中起来，按「现象 → 原因 → 解决」的格式写。这些都是真实会遇到的情况，不是理论推演。

5.1 自增主键耗尽或分页深翻页变慢

现象：图书表 id 增长很快，几个月后接近 INT 上限；后台管理列表翻到 100 页时，接口响应时间从 200ms 涨到 3 秒。

原因：第一，id用了INT而不是BIGINT，假设一天新增 500 条书目，INT 上限 21 亿看起来很多，但如果你在测试环境反复导数据、回滚事务，自增 ID 不会回退，大量消耗之后会有耗尽风险。第二，深层分页的LIMIT 20000, 20会让 MySQL 先扫描前 20000 行再丢弃，这种「深翻页」问题靠索引也救不回来。

解决：主键统一用BIGINT；深翻页改为基于上一页最大 ID 的游标查询，例如WHERE id < 上一页最小id ORDER BY id DESC LIMIT 20。如果这个系统未来要对接大屏展示或报表统计，深分页轮询很常见，尽早改成游标式分页能省很多事。

5.2 学号与 ISBN 字段类型选错，导致无法走索引

现象：student表查某个学号时，明明建了唯一索引，EXPLAIN 却显示type = ALL全表扫。

原因：student_no字段被定义成了INT，而应用层传来的学号是'20240501'字符串。MySQL 在比较 INT 字段和字符串时，会先把字符串转成数字再比较，索引失去作用；更糟糕的是如果你的学号存在前导零（020240501），转成 INT 后前导零直接丢失。ISBN 同理，它虽然由数字组成，但本质不是数值，而且长度超过 INT 范围。

解决：学号、工号、ISBN、条形码这类业务编号一律用VARCHAR(20)或更长，不要省空间用数值类型。这道坑的隐蔽性在于小数据量时全表扫也很快，上线初期很难发现，等数据到了几万条才开始出现明显慢查询。

5.3 借阅流水表无限膨胀，历史数据拖慢在线查询

现象：系统跑了一年多，borrow_record表超过 50 万行，首页的「当前借出」查询也跟着变慢。

原因：所有历史借阅记录都在同一张表里，查询「当前借出」时即使走了status索引，索引页和数据页也越铺越大，缓存命中率下降。status = 1的记录只占全表的很小比例，但 InnoDB 的聚簇索引结构决定了扫描开销和表大小正相关。

解决：按年做分区表，例如按borrow_time做 RANGE 分区。这样查询当前借出时，如果 SQL 条件带上了时间范围，分区裁剪会让 MySQL 只扫当年分区，大量历史分区直接跳过。注意分区键必须包含在查询条件里才有效，所以业务代码里查借阅列表要习惯性地带上时间范围。如果未来数据量更大，可以把三年以前的流水归档到历史库，在线表只留最近时间段，归档用定时任务迁移，这是一条长期运维必须做的路。

5.4 并发扣减库存出现负数，但并没有报错

现象：同一本热门书在开学季高峰期出现available_copies = -1，借阅列表上显示这本书「可借 -1」。

原因：借书事务里没有把「扣减可借数量」和「校验库存 > 0」写进同一条 UPDATE，而是先 SELECT 判断库存再 UPDATE 扣减，两个操作之间有窗口期，两个并发请求都通过了 SELECT 的库存判断，然后都执行了 UPDATE。

解决：回到第 4 章写的模式，用UPDATE ... SET available_copies = available_copies - 1 WHERE id = ? AND available_copies > 0，应用层检查影响行数。这条经验适用于任何库存类业务，不只是图书系统。另外可以在book表加一个CHECK (available_copies >= 0)约束，虽然 MySQL 对 CHECK 的强制执行版本有差异，但加上总比没有强，在 8.0.16 之后的版本它是有效的。

5.5 逻辑删除和物理删除混用，导致借阅历史对不上账

现象：管理员删除了一条误录的借阅记录，后来统计某本书的借阅热度时，数据偏小，读者借阅历史也出现缺口。

原因：删除操作直接执行了DELETE FROM borrow_record WHERE id = ?，而系统其他地方都是逻辑删除，两种模式混用后数据对不齐。借阅流水一旦产生，就属于账目性质的数据，不能物理删除，即使录错了也只能「撤销」并补一条正确的，保证审计线索完整。

解决：borrow_record表禁止任何物理 DELETE，只允许用状态字段流转，比如状态为 5 表示已撤销。同样的逻辑也适用于copy表，副本丢了要改成状态 4（丢失），而不是删掉，这样盘点和历史追溯才有据可查。我建议在应用层做一个全局拦截：对这三张表的所有删除操作一律返回「不支持物理删除」，倒逼开发人员走状态字段。

6. 从数据库到 Spring Boot：DAO 层映射与查询优化的四个细节

基于当前主流的开发方式，这个系统大概率会用 Spring Boot 来承载接口，数据库则用 MyBatis 或 JPA 做映射。前面设计和建表做得再好，DAO 层的几个细节写不对，照样会在运行期出问题。这一章讲四个我每次做这类系统都会检查一遍的细节，它们的效果可以用 EXPLAIN 和慢查询日志直接验证。

6.1 MyBatis 的 resultMap 与驼峰映射：别让 XML 写成了体力活

学校图书借阅管理系统的实体类通常按 Java 驼峰命名，比如borrowTime，而数据库字段是下划线borrow_time。MyBatis 如果没开驼峰映射，每个字段都要手写resultMap，列表查询十几个字段的映射代码又臭又长，还容易漏字段导致运行时 NullPointerException。

mybatis: configuration: map-underscore-to-camel-case: true

这个配置在 Spring Boot 的application.yml里一行搞定。它让 MyBatis 自动把borrow_time映射到borrowTime，省去写 resultMap 的工作量。但有个前提：实体类字段必须严格遵循驼峰命名，数据库字段必须严格使用下划线风格。如果个别字段没对齐，比如数据库里是book_title而 Java 字段叫name，那还是得单独写 resultMap 覆盖。我的习惯是「全局驼峰映射 + 特例 resultMap」两条腿走路，既省事又不至于在大查询里迷失。

6.2 JPA 的懒加载与 N+1 查询问题

JPA 的方式则要防另一个坑。用@OneToMany关联借阅流水时，如果默认走懒加载，遍历学生列表时每查一个学生就发一条流水查询 SQL，100 个学生就是 101 条 SQL，这就是典型的 N+1 问题。解决方法是把查询写成 join fetch，或使用实体图，在一条 SQL 里把数据取出来。

@Query("SELECT DISTINCT s FROM Student s LEFT JOIN FETCH s.borrowRecords WHERE s.status = 1") List<Student> findActiveStudentsWithRecords();

这里要提醒的是LEFT JOIN FETCH配合分页时，MySQL 的limit是在内存里做的，数据量大后会有性能问题。如果你既要做关联查询又要分页，更稳妥的方案是拆成两条查询：先分页查出学生 ID 列表，再用WHERE student_id IN (...)查流水，最后在内存里组装。牺牲一点代码整洁度，换来的是可预期的数据库执行计划。

6.3 批量归还接口的 SQL 聚合：减少数据库往返

还书功能往往是一次还多本，很多新手在循环里逐本执行归还事务，一次还 10 本书就是 10 次事务往返。更好的做法是应用层先校验所有流水状态，再分两条 SQL 批量完成：一条UPDATE borrow_record SET status = 2, return_time = NOW() WHERE id IN (...)，一条UPDATE copy SET status = 1 WHERE id IN (...)。然后对每本书的available_copies做累加，逐本更新。数据库事务仍然包裹整个批次，但网络往返从 30 次降到 10 次以内。

这里要权衡的是，批量更新时如果其中一本状态异常导致更新行数为 0，整个事务要不要回滚？我的做法是全部回滚，让用户重新提交，这是最不容易出错的状态一致性方案。如果你觉得这样对用户不够友好，至少要记录失败的 ID 并让前端明确提示哪些书归还失败，绝不能「大部分成功、部分失败」但接口返回值是成功。

6.4 用 EXPLAIN 和慢查询日志验证索引设计，而不是靠感觉

每张表建完索引后，我会把核心查询拿出来跑一遍 EXPLAIN，重点看type列和rows列。

EXPLAIN SELECT * FROM `borrow_record` WHERE `status` = 1 AND `due_time` < NOW() ORDER BY `due_time` ASC LIMIT 20;

如果type显示range、rows值在几千以内，说明索引起作用了；如果type是ALL或rows到几十万，就该检查是不是联合索引的列顺序错了。慢查询日志也要在运维期开着，阈值设 1 秒，每周扫一遍，借阅系统 90% 的性能问题都能在慢查询日志里找到源头。这套方法不完全依赖工具，你只要在这条路线上形成习惯，每加一个功能就顺手验证一次，系统到上线后基本不会出现「突然全站卡死」的惊魂时刻。

说回我自己的教训：我最早设计图书借阅系统时，把borrow_record当成了纯粹的流水表，只存student_id和copy_id，书名每次都靠 join 去查。上线两个月后列表页越来越慢，DBA 查出来的慢查询全是那几条 join 三张表的统计 SQL。后来痛定思痛，把冗余字段加回去、把联合索引按查询场景重排了一遍，同样的接口从 800ms 降到了 120ms。这个经历让我养成了一个习惯：每写一条查询，先问自己这条 SQL 要遍历多少行数据，如果超过一万行就停下来重新审视索引和表结构。做数据库设计，永远不要在「看起来能用」的地方停下，因为上线后的每一次优化，都要比设计阶段付出大得多的代价。希望这份设计笔记能帮你在一开始就避开这些弯路。

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