图书馆管理系统数据库设计：六张表撑起借还业务闭环

1. 需求与范围：先把"图书馆管理系统"到底要管理什么盘明白

做这个数据库版的图书馆管理系统之前，我建议你先别急着建表。很多新手拿到题目就直接开库建表，做着做着发现漏了功能，回头改表结构，改到后面数据乱成一锅粥。我在实际接触这类系统时，习惯先用一页纸把需求边界画清楚。

无论你是做课程设计、毕业设计，还是在公司内部做个图书管理的小工具，这一类系统的核心对象都不外乎三个：图书、读者、借还记录。围绕这三个对象，基本功能可以拆成几大块：

• 图书管理：新增图书、编辑信息、下架删除、查询库存、图书分类管理
• 读者管理：读者信息录入、借阅证状态管理（挂失、注销）、读者分类（学生/教师等）
• 借还业务：借书、还书、续借、预约、逾期处理和罚款计算
• 统计查询：热门图书排行、读者借阅排行、图书库存预警、借阅流水查询

你可以先做一个功能清单，标注出"必须做"和"有余力再做"两档。比如最基本的课程设计，借书、还书、图书查询、读者管理这四件事就是必须项；预约和续借属于加分项；如果做成公司内部真实使用的工具，可能还要加操作日志、权限区分（管理员和普通读者看到的界面不同）、条码扫描支持。

我第一次做一个“图书馆管理系统（数据库版）”的时候，范围没控制住，什么功能都想塞进去，结果数据库设计了二十多张表，开发到一半自己都晕了。后来我换了个思路，先只做最核心的四张主表和一张关联表，把借还主流程跑通，再逐步叠加周边功能。这么做的好处是，只要核心数据模型设计得合理，后面加表、加字段都不会伤筋动骨。

接下来就是把这些需求翻译成数据库能理解的语言。这里面最关键的一步，不是写SQL，而是把"业务规则"想清楚。有一些你以为是约定的规则，实际上会影响表结构设计。举三个例子：

1. 一本书可以买多本副本（复本），比如《活着》馆藏3本，有的书只有1本。这意味着"图书"和"图书副本"应该是两张表，或者至少图书表里要有"总馆藏数量"字段，并拆出明细记录。
2. 一个读者最多能借几本书？逾期一天罚多少钱？这些参数最好做成系统里可配置的，而不是写死在代码里。为了配置灵活，数据库设计时就要预留参数表，或者你至少要在文档里说清楚规则。
3. 还书时，系统到底是记录"应还日期"还是还要记录"实际归还日期"？如果只有一张借阅流水表，那借出去和还回来都写在同一张表里，靠字段区分当前状态；如果拆成借书单和还书单两张表，统计会更灵活但实现更复杂。

这些边界问题，几乎决定了你后面表结构长什么样。我不能替你拍板所有规则，因为不同场景需求确实不一样，但后面的章节我会给出一个拿来就能用的默认设计。多数情况下，这个设计可以直接应对课程设计和中小型实际项目。

2. 核心表结构设计：六张表撑起一套系统

先把结论放出来，这是我在多个类似项目中打磨过一套六张表的方案，功能上不臃肿，结构上也不单薄，适配"数据库版"这个定位刚刚好。

2.1 图书信息表（book）

这里有个容易混淆的概念必须讲清楚：book_id是书目ID，一本书目对应一个唯一的书名和作者组合；而后面要说的book_copy_id（副本ID）才对应物理上的一本本实体书。为什么这样拆？因为图书馆采购时经常一次买多本一样的书，它们共享同样的书目信息，却有不同的借出状态——一本被别人借走了，另一本还在架。如果你不拆这个概念，用"剩余数量"字段硬扛，会面临几个问题：无法知道具体哪一本被借走、续借和预约无法对应到具体实体书、盘点时也无法核对物理实物。

但是，如果我不拆表，单用一个total_stock和available_stock行不行？对于课程设计来说，其实也能跑通。借书时判断available_stock > 0，减一；还书时加一。好处是简单，缺点是查不了"某本书的借阅历史"，也做不了"哪一本副本目前被谁借走"的明细追踪。考虑到我这个示例希望做到既不太复杂又足够专业，我的建议是：以书目为主表进行基础管理，同时在借阅业务层面用"副本逻辑"控制可借数量。你可以在设计文档中保留副本表的设计意图说明，工程上暂用数量字段控制。真要引入副本表，就是在book和borrow_record之间再插一张book_copy表作为桥梁，后续扩展不推倒重来。

2.2 读者信息表（reader）

max_borrow字段要不要存到每个读者上？很多系统会放在读者类型表（reader_type表）里，比如"学生最多借5本，教师最多借10本"。两种做法各有优劣：把上限放在读者表里，处理个别读者特殊权限时非常灵活；放在类型表里则规则更集中、便于统一修改。我的实践经验是，中大型系统用独立类型表更合理，但在数据库课程设计级别的小系统里，直接在读者表里加字段也完全够用，而且少一张表就少一次关联查询。注意，如果你用独立类型表，读者表里存的是reader_type_id外键；如果不用，就直接存一个描述性字段。

2.3 图书分类表（category）

CREATE TABLE category ( category_id INT PRIMARY KEY AUTO_INCREMENT, category_name VARCHAR(50) NOT NULL UNIQUE, parent_id INT DEFAULT NULL, sort_order INT DEFAULT 0, description VARCHAR(200) );

分类表我单独列出来，是因为很多初学者容易忽略它。如果你不在数据库层面做分类，而只是把"文学类""计算机类"这些词当一个普通字符串存在图书表里，那么后续改分类名时，就要批量UPDATE图书表，非常痛苦，还可能改漏。有了一张分类表，图书表里只需要存一个分类ID，界面展示、统计报表都要舒服得多。

parent_id字段是为了支持二级分类。比如"图书"下面分"文学"和"计算机"，"计算机"下面再分"编程语言""数据库"。如果系统要求不高，一级分类就够了，那parent_id可以不用管，默认NULL就行。这个字段留着没坏处，万一需求变了要加父级分类，不用改表结构。

2.4 借阅记录表（borrow_record）

这是整个系统里业务逻辑最重的一张表。借书、还书、续借、预约、逾期判断、罚款计算，全部围绕它展开。我建议这样设计：

这张表的字段设计有几个值得琢磨的地方：

• return_date可空。这是判断书是否在馆的根。如果为NULL，表示这本书还在读者手上，对应的available_stock应该已经减过一了；一旦还书，就写入实际时间。前端想查"谁还没还书"，一句WHERE return_date IS NULL就出来了。
• status和return_date存在信息重叠。一个人还了书，return_date非空，此时status一定是"已归还"；一个人逾期了，due_date已过但return_date是NULL，此时status可能是"借出中"，也可以由定时任务把它刷成"逾期"。为什么又要字段又要判断日期？因为直接用日期判断虽然也能得出结果，但在频繁访问的页面上，每次查询都计算一遍due_date < NOW()很消耗性能。后台定时任务提前把逾期记录标记起来，前台查询便只查索引列，效率更理想。当然，如果只是课程设计，完全可以不单独设置status字段，查询时实时计算也是可取的方案。
• renew_count用于限制续借次数。业务规则是"每本书最多续借两次、每次延长30天"，那每次续借前都要查一下已续借的次数，超过就不再允许。

2.5 罚款记录表（fine_record）

罚款单独设一张表，而不是在借阅记录表里加一个fine_amount字段，主要是因为一次借阅可能会产生多笔罚款——先逾期产生一笔，后来发现书还被画花了又产生一笔。用独立表才能把"一条借阅记录"和"多笔罚款"对应起来。另外罚款的"未缴/已缴"状态也只有在独立表里才管理得住。

2.6 管理员表（admin）

CREATE TABLE admin ( admin_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, real_name VARCHAR(50), role TINYINT DEFAULT 1, last_login_time DATETIME, login_ip VARCHAR(50), status TINYINT DEFAULT 1 );

管理员表要注意的是密码字段。我强烈建议别用明文保存密码，哪怕做课程设计也不要图省事。你至少用MD5或SHA256哈希一下再入库，等学了更正规的方案以后换成加盐哈希甚至bcrypt都行。数据库版的项目如果表结构里躺着明文密码，答辩时被问"安全性怎么考虑"，这一关很难圆回来。

至于管理员表需不需要分角色（超级管理员、普通管理员、图书管理员），看系统规模。小系统一个role字段就够，大系统可能要独立的权限表和角色表，此处不展开。

这六张表合在一起，就是一个能支撑完整业务闭环的最小集。接下来我讲讲表之间的外键关系和索引规划，这一块才是"数据库版"含金量的体现。纯CRUD谁都会，但能讲清楚"为什么这个外键要加、这个索引为什么建在联合列上"的人，才算是真正把数据库原理用进项目里。

3. 关系梳理与完整性约束：外键怎么加、索引怎么建、数据怎么保证不乱

3.1 实体关系

先明确关系：图书分类与图书是一对多（一个分类下有多个书目）；读者与借阅记录是一对多；图书与借阅记录是一对多（一个书目会被反复借出）；借阅记录与罚款记录是一对多。这个关系图在论文或设计文档里画成标准的ER图即可，真正的难点在于外键约束要建在哪一侧、CASCADE还是RESTRICT。

有经验的开发者给外键加约束时会非常谨慎。这里不是不用外键，而是要知道每种选择带来的后果。我举几个在实际开发中非常容易踩到的场景：

1. 删除分类时，该分类下还有图书怎么办？如果外键设置了ON DELETE CASCADE，删分类会把图书也连带删掉——这通常不是我们想要的。更合理的是ON DELETE RESTRICT或SET NULL。RESTRICT会在你试图删除被引用的分类时直接报错，逼你先处理分类下的图书（比如把书重新分类或下架），这种"粗暴但安全"的做法在管理类系统中非常合适。
2. 删除读者时，该读者有未还的图书怎么办？如果你用物理删除，把读者记录直接DELETE掉，那借阅记录表里就出现了一个悬空引用。假如你前期没加外键约束，后期查统计就查到一堆"幽灵借阅"。两全的做法是业务上不做物理删除，而是把reader.status字段改为"注销"，保留记录。这是数据管理领域"软删除"思路，类同橡皮擦抹去一个本子上的铅笔字不及附着痕迹撕掉整页纸。
3. 借阅记录表的book_id和reader_id外键要不要加？建议加。课程设计的答辩环节，老师最爱问的就是"如果借阅记录指向的图书被删了，怎么办"。有了外键约束，你在代码里还需要考虑异常捕获，但数据库层面至少兜了底。

3.2 索引设计

索引不是越多越好，但下面这几个高频查询路径值得建索引：

• 图书表的title和author。图书查询几乎都走"按书名模糊查"或"按作者查"，但LIKE '%关键词%'这种写法是索引失效的高发区。它会退化成全表扫描。如果你只需要前缀匹配（比如"数"开头的词），用LIKE '数%'就可以命中索引。但现实中用户很可能只记得中间几个字，这时索引作用有限，我们往往还需要配合全文检索方案。这个我在第5章再细聊。
• 借阅记录的(reader_id, status)联合索引。典型查询"查询某人当前借了哪些书"，走这个联合索引会非常快，因为它可以直接定位到读者ID，再在status上过滤一次。还有另一种高频形态是"查所有逾期未还的书"，这种查询的过滤条件是due_date < NOW() AND return_date IS NULL，索引应该建在(due_date, return_date)上。
• 罚款记录的(reader_id, status)联合索引。用于前台展示"某人还有哪些罚款没缴"。
• 图书表的(status, category_id)联合索引。用于"查询上架状态下的某分类图书列表"。

有些读者会习惯性地给每个可能查询的列都建单列索引，这样效果并不好。MySQL在同一时刻往往只能选择一个最有选择性的索引，其他索引只能干瞪眼。正确的思路是先找出"最常作为条件的列组合"，为这些组合建联合索引。建索引快、查询未必快；建得不合理反而拖慢增删改，得不偿失。

3.3 数据一致性保障

表结构设计好之后，很多新手会忽略的一个问题是"并发"。

想象一个真实场景：有一本书只剩最后一本可借了，同时来了两个同学在柜台前都要借这一本。如果代码先查询available_stock是否大于0，再执行UPDATE，那么两个请求同时查到的可能都是1，然后都通过了判断，最后大家一起UPDATE出一个负数库存。这就是典型的并发竞态条件。

解决的办法并不需要上多高深的技术，核心思路是让"检查+扣减"成为一个原子步骤。SQL里可以这样写：

UPDATE book SET available_stock = available_stock - 1 WHERE book_id = ? AND available_stock > 0;

这句话的妙处在于，它把"检查库存是否足够"和"扣减库存"合并到了同一条UPDATE语句中。数据库在执行这一行时会锁定对应的行记录，另一个请求再执行同样的UPDATE时，会因为available_stock > 0不满足而影响行数为0。如果你用ORM框架，执行完这行SQL后再检查一下影响行数：是1则借书成功，是0则说明没抢到。

同样的思路也适用于还书操作：还书时available_stock = available_stock + 1，不涉及条件判断，相对安全。但你要注意整个流程应该放在一个事务里——写入借阅记录和更新库存数量不能一个成功一个失败。用事务把它们包起来，任何一个环节出错都回滚。

说到事务，Book借出场景的事务边界是这样的：

START TRANSACTION; INSERT INTO borrow_record (reader_id, book_id, borrow_date, due_date, status) VALUES (?, ?, NOW(), DATE_ADD(NOW(), INTERVAL 30 DAY), 1); UPDATE book SET available_stock = available_stock - 1 WHERE book_id = ? AND available_stock > 0; -- 检查上一步影响行数，如果为0则ROLLBACK COMMIT;

还书场景同理：

START TRANSACTION; UPDATE borrow_record SET return_date = NOW(), status = 2 WHERE record_id = ? AND return_date IS NULL; UPDATE book SET available_stock = available_stock + 1 WHERE book_id = ?; -- 如果存在逾期，生成罚款记录 COMMIT;

这段逻辑说起来简单，但能做到的人真不多。尤其是大学阶段做数据库课程设计的同学，很多人直到答辩都没碰过事务，全凭代码里一个个操作堆硬叠。真出了问题只能重启重置数据解决。我的建议是：把事务和并发控制作为这个项目的"亮点"写进设计文档，这也是答辩/考核时最拿得出手的数据库知识储备。

4. 完整开发流程拆解：从建库到功能实现的最短路径

4.1 阶段一：建库建表，先把骨架搭好

用SQL脚本一次性建好所有表比后续一个表一个表地建要省心得多。上面说到的六张表，加上适当的外键、索引、默认值，一份完整的建表脚本大概一百多行。我不建议在这里贴超长脚本，但有一个小技巧值得分享：在写建表脚本时就把注释写全，无论是数据库字段的COMMENT还是程序里的代码注释，越详细越好。写注释看起来是浪费时间，但是两周后再返工维护这个系统时，你会感谢当初的自己。

建表时还有几个默认值陷阱要注意：

• 日期字段别设置成DATETIME DEFAULT CURRENT_TIMESTAMP以外的东西。CURRENT_TIMESTAMP会随每行插入自动填充，省得业务代码里手动传参。
• 浮点金额一律用DECIMAL，不要用FLOAT/DOUBLE。二进制小数不能用精确值表达十进制小数这个坑，做支付、罚款这类跟钱打交道的业务时特别容易触雷。0.1在二进制里存的是一个近似值，累积到成百上千条记录时差会越来越明显。
• TINYINT作为布尔或枚举使用时，强烈建议加上CHECK约束（如果用的数据库支持的话），或者至少在注释里写明哪个数字代表什么状态。这能防止程序里塞进意想不到的值，比如status = 9查不出对应含义。

4.2 阶段二：实现图书与读者管理模块

这个阶段相对机械，本质是几张基础表的"增删改查"。但有一个细节值得用心优化，那就是图书的综合查询。

一个合格的综合查询界面，至少要支持按书名模糊查、按作者查、按分类查、按ISBN精确查，还要支持上述条件的任意组合。不推荐代码里拼接出无数种SQL组合，一个更简洁的方法是采用"动态拼条件"的思路：

SELECT * FROM book WHERE 1 = 1 AND (title LIKE CONCAT('%', ?, '%') OR ? = '') AND (author LIKE CONCAT('%', ?, '%') OR ? = '') AND (category_id = ? OR ? = 0) AND (status = ? OR ? = -1);

骑着小木驴慢慢跑的说法是"我不管用户传了什么参数进来，拼SQL时每加一个条件就先判断参数是否为空，空就跳过"。这种写法在应用层看起来可能有点繁琐，但它是所有ORM框架动态查询的底层原理。理解了它再去用MyBatis的动态SQL或JPA的Specification，都是一通百通。

读者管理模块里，还有个常常被忽略的点：借阅证号需要唯一。一张借阅证对应一个读者，很多系统会忘记给card_no加唯一索引，导致重复办证。严重时，同一个证被两个"读者"同时使用，借还记录就会张冠李戴。这种问题还特别隐蔽，往往运行好几个月后才被一次性爆出来。

4.3 阶段三：借书还书主流程

这个阶段是整个系统的心脏。前面第3章讲的事务和行级锁在这里要真正落进代码里。我再补两个细节：

借书流程：先检查读者是否存在且状态正常（没挂失、没注销）；检查读者的max_borrow，统计当前在借数量是否已经达到上限；检查该书是否有可借副本；扣减库存并插入借阅记录；最后检查读者是否有未缴罚款，如果超过指定金额（比如累计超过100元），禁止继续借书。这一套规则走下来，只有全部通过才能成功借书。

还书流程：定位到对应的借阅记录，必须满足return_date IS NULL；计算实际借阅天数，如果超过due_date，按每天一个固定金额（比如0.5元）计算逾期罚款，并自动生成一条罚款记录；然后归还库存、更新借阅记录状态。这里特别强调一个容易被忽略的边界情况：用户还的不是最新一次借的那本书，而是很久以前的遗留记录。如果数据库允许同一读者同一本书多次借阅，还书时你定位到哪一条？必须在业务上规定，要么同一读者同一本书同时只能有一笔未还记录，要么还书时指定具体是哪一次借的（借阅记录ID）。

4.4 阶段四：统计查询与报表

最后一个阶段是锦上添花的统计功能。常见的统计需求有：

• 热门图书排行（按借阅次数TOP N）

SELECT b.title, COUNT(br.record_id) AS borrow_count FROM book b JOIN borrow_record br ON b.book_id = br.book_id GROUP BY b.book_id, b.title ORDER BY borrow_count DESC LIMIT 10;

• 读者借阅排行（按借阅次数TOP N）

SELECT r.name, COUNT(br.record_id) AS borrow_count FROM reader r JOIN borrow_record br ON r.reader_id = br.reader_id GROUP BY r.reader_id, r.name ORDER BY borrow_count DESC LIMIT 10;

• 当前逾期未还清单

SELECT r.name, b.title, br.due_date FROM borrow_record br JOIN reader r ON br.reader_id = r.reader_id JOIN book b ON br.book_id = b.book_id WHERE br.return_date IS NULL AND br.due_date < NOW();

这类统计SQL没什么玄机，但要提醒一句：避免在统计查询中扫描整表的历史数据。等借阅记录表积累到几十万行甚至上百万行，一个不带任何时间过滤的报表查询很容易拖垮库。设计方案时给报表查询加上时间范围参数（默认查最近一个月、最近一年），既符合使用场景，也符合SQL优化的基本常识。

5. 用不上的时候可以不做的内容不算没有用：续借、预约、逾期自动标记

前面讲的是基础版本。如果你的项目在基本功能之外还需要一些加分项，接下来这几个扩展需求是现实中经常提到、也比较容易啃下来的硬骨头。

5.1 续借功能

续借的本质不是"改一下还书日期"，而是"在满足条件的前提下，把截止日期向后推，同时标记续借次数"。

需要校验的条件至少有三点：

1. 该书当前还没有被其他读者预约（这个是预约功能引入后自然带出来的约束）；
2. 该读者的续借次数没达到上限（比如最多两次）；
3. 该书当前没有逾期（如果已经逾期，要先处理罚款才能续借，或者干脆不允许续借）。

SQL实现倒是不难：

UPDATE borrow_record SET due_date = DATE_ADD(due_date, INTERVAL 30 DAY), renew_count = renew_count + 1 WHERE record_id = ? AND return_date IS NULL AND renew_count < 2 AND due_date > NOW();

老规矩，判断是否更新成功就看影响行数是否为1。这个策略的好处是数据库层面直接把所有校验条件锁进了一条语句，应用层几乎不需要再担心并发问题。

5.2 预约功能

预约功能是一个不太适合"数据库版"的入门阶段就上马的功能，但要实现也不难，核心是一张预约表：

CREATE TABLE reservation ( reservation_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, reader_id INT NOT NULL, reserve_date DATETIME DEFAULT CURRENT_TIMESTAMP, status TINYINT DEFAULT 0, expire_date DATETIME );

业务逻辑大致是：读者对已借完的书发起预约；当有人归还这本书时，系统扫描预约表中针对该书最早的待处理预约，通知该读者来取书；此时这本书进入"预留状态"，不能借给别人；预留超过一定时间（比如72小时）读者没来取，预约自动取消，书重新回到架位。

这一套流程里，删掉最复杂的通知机制后，核心就是"还书时判断是否有预约"这一个判断点。代码写起来不难，但要处理的状态比较多，属于"看着容易、做着繁琐"的类型。如果做的是课程设计，我建议在文档里说明有预约模块设计思路，工程实现上把它标记为二期迭代，反而是更务实的取舍。当然，如果你精力足够，完全可以实现个简化版：只是生成预约记录，不做自动通知和过期释放。

5.3 逾期自动标记

我前面说过，逾期状态可以由定时任务更新。典型的定时任务逻辑是每天凌晨执行一次：

UPDATE borrow_record SET status = 3 WHERE return_date IS NULL AND due_date < NOW() AND status = 1;

同时，在同一个任务里生成逾期罚款记录：

INSERT INTO fine_record (record_id, reader_id, amount, fine_type, status) SELECT record_id, reader_id, DATEDIFF(NOW(), due_date) * 0.5, 1, 0 FROM borrow_record WHERE return_date IS NULL AND due_date < NOW() AND record_id NOT IN ( SELECT record_id FROM fine_record WHERE fine_type = 1 AND status = 0 );

这条SQL里的核心是DATEDIFF(NOW(), due_date) * 0.5，即每天0.5元的逾期费。同时用NOT IN子查询防止对同一笔借阅重复生成罚款。定时任务在很多教材里很少讲，但实际项目几乎天天用。如果能在设计文档里写明这个方案，然后写一个简单的Spring定时器、Quartz任务或Windows计划任务，这个项目在"工程化能力"上的得分会明显不一样。

6. 实战避坑清单与经验心得：这些坑我基本都踩过一遍

最后这部分算是我个人几次做类似项目的经验汇总，没有优先级顺序，想到哪写到哪，但每一条背后都有一次真实的返工或排查经历。

6.1 字符集与排序规则

很多人在本机上开发一切正常，一部署到服务器就发现中文乱码。根因通常是建库时的字符集。创建数据库时请直接指定：

CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4是UTF-8的超集，能存下表情符号、生僻字、扩展汉字，MySQL 8.0之后更是默认配置。Java开发的话，还要注意JDBC连接串上加characterEncoding=utf8和useSSL=false。排序规则utf8mb4_general_ci表示"大小写不敏感、中文按拼音排序"，对图书按书名排序的场景非常友好，不然查"计算机"和"计算机"这种输入差异会导致排序结果不稳定。

6.2 日期时间类型的"时区幻觉"

这个坑我实际踩过：数据库存的时间比北京时间早了8小时，查出来明明正确，页面上却少了一天。原因很简单，数据库服务器时区和你应用服务器时区不一致。Java 8的LocalDateTime不会自动带上时区信息，存在库里就是一串本地时间数字，只有Instant这种类型才会按UTC存储再按本地时区展示。稳妥做法是：数据库连接串上明确指定serverTimezone=Asia/Shanghai，同时让数据库服务器与应用服务器使用同一时区。这是一个小细节，但所谓"数据库版"项目如果上线后发现借书日期全偏了，排查起来会非常头痛。

6.3 SQL注入与预编译

哪怕只是一个课程设计，我建议也在DAO层或Service层始终坚持使用预编译语句（PreparedStatement）或参数化查询，绝不要用字符串拼接SQL。

// 错误示范 String sql = "SELECT * FROM reader WHERE name = '" + inputName + "'"; // 正确示范（以JDBC为例） String sql = "SELECT * FROM reader WHERE name = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, inputName);

PreparedStatement的好处不只是防SQL注入，它还会让同一条SQL咖喱快速执行——数据库可以把SQL解析一次的缓存利用起来，高并发下性能也有提升。实际项目中那些"忘了加引号就报错"的诡异问题，多半也是拼接SQL引起来的。

6.4 软删除思维

前面已经提到了软删除，这里再补充一个细节。在做图书下架时，很多新手会直接DELETE FROM book WHERE book_id = ...。如果这本书有借阅记录、甚至现在正被人借阅，物理删除会导致历史记录变成悬空数据。相比直接DELETE，真正安全的方式是：

UPDATE book SET status = 0 WHERE book_id = ?;

然后借书时默认加上AND status = 1条件。这个"下架而非删除"的思路在真实业务系统里是标配，很多公司把这种设计叫"逻辑删除"。它会体现在你最终表里多出的status字段上，评价你系统时也是专业度的体现。

6.5 备份和恢复

最后这一点可能不是所有课程设计都要求，但作为"数据库版"项目，向老师或团队展示你懂得数据库运维，是很加分的点。至少养成一个习惯：每天导出一份SQL备份。

mysqldump -u root -p library_db > library_backup_$(date +%F).sql

恢复也就一条命令：

mysql -u root -p library_db < library_backup_20241201.sql

当然，生产环境下会配合binlog做增量备份，但作为入门项目，日备策略已经足够说明你在数据安全上是有考量的。

6.6 事务隔离级别的选择

如果你的系统业务量不大、并发不高，默认的事务隔离级别即MySQL的REPEATABLE READ完全够用。这个级别下能保证"同一个事务里多次读到的结果一致"，借书和还书流程也不容易出幺蛾子。不需要追求更高级别的SERIALIZABLE，它会让并发性能断崖式下降，属于"看着强、用起来痛"的典型配置。如果未来要往高并发方向走，再研究READ COMMITTED与MVCC的取舍。

这个系统的整体开发过程相对完整地走下来，从需求拆分到建表、到写业务、到调优、到避坑，其实12~16学时的集中精力就能完成。最关键的是，不要急着写代码，先把表结构和事务边界想透。数据模型一旦定下来，后期的修改成本是滚雪球式上升的。先想清楚再动手，比任何快捷键都有效。