SQL数据库设计实战：图书管理系统中isborrowed状态与外键约束的取舍

简介：一份基于SQL数据库的图书管理系统完整课程设计文档，面向计算机专业学生与数据库入门开发者，用于解决传统人工管理中信息混乱、重复劳动等问题。系统以读者信息、图书信息、操作员信息为核心模块，覆盖借书、还书、超期罚款等业务流程。资源共1个doc文档，大小约709KB，内容集中在设计报告书中，包含系统背景、数据需求分析、E-R图、数据字典、关系模式及SQL实现代码。文中对书籍类别、读者、书籍、借阅、还书、罚款等关系模式做了完整建模，并配有数据流程图与功能说明，能帮助读者掌握从概念设计到SQL落地实施的全过程。已有2317人浏览学习，适合需要完成数据库课程设计或快速上手SQL项目实践的读者。

1. 一套 SQL 数据库图书管理系统：isborrowed 字段为什么是整张表的心脏

isborrowed 只有两个字符，却是这套 SQL 数据库图书管理系统的“安全气囊”。翻开这份课程设计报告，第一眼看到的是 E-R 图、数据字典、六张表的建表语句和一长串 INSERT 初始化脚本，第二眼才会注意到图书表里那个取值只有 0 和 1 的标记字段。为什么明明有借阅记录表，能查到谁借了哪本书，还要在图书表里专门放一个“状态副本”？这个看起来多余的字段，恰好把关系型数据库里一个经典矛盾摆到了台面：既要完整记录每一笔业务流水，又要让“这本书现在能不能借”这类高频查询足够快。把 isborrowed 的同步机制吃透，才算真正看懂这套系统。下面从六张表的外键骨架开始拆。

2. 六张表与四组外键：实体关系是怎么被翻译成数据库约束的

2.1 从 E-R 图到关系模式：实体、属性和联系如何落地成表

原报告把图书管理信息系统划分成六个实体：书籍类别、读者、书籍、借阅记录、归还记录、罚款记录，然后按经典转换规则落到关系模式。书籍与类别是典型的多对一：一本书只属于一个类别，一个类别下有多本书，转换时把“类别编号”作为外键塞进书籍表；读者与书籍之间是多对多，一个读者可以借多本书，一本书可以被不同读者在不同时间借走，多对多不能直接建一张表，必须拆出“借阅记录”作为中间关系，再把读者编号和书籍编号分别作为外键。

我一般会这么理解这套关系模式的骨架：类别表是“字典”，读者表和图书表是“主数据”，借阅、还书、罚款三张表是“流水”。字典主数据可以在业务发生前就初始化，而流水每产生一笔业务就追加一行。罚款表比较特殊，它把读者姓名、书名、借书时间都冗余进来了，看起来不符合第三范式，但它本质是“借阅流水的一个派生快照”，方便直接输出罚款单，不需要临时 JOIN 四张表。这种“主数据 + 流水 + 快照”的划分，比单独记住哪张表有几个字段更能指导后续设计。

2.2 数据字典里的类型约定：varchar 主键、datetime 登记日期与冗余字段

报告中的数据字典定义了每张表的列名、类型、可空性和说明，把关键约定浓缩成一张表：

表名	主键	外键	业务含义
book_style	bookstyleno	无	书籍类别字典
system_books	bookid	bookstyleno → book_style	图书主数据，含 isborrowed 状态
system_readers	readerid	无	读者主数据
borrow_record	bookid	readerid → system_readers, bookid → system_books	借阅流水
return_record	bookid	readerid → system_readers, bookid → system_books	还书流水
reader_fee	bookid	readerid → system_readers, bookid → system_books	罚款快照

几个值得注意的设计选择：主键全部用 varchar 而不是 int 自增，借书证编号、书籍编号这些业务编号本身就有可读性，比如 Q001 一看就是学生证段位，901 一看就是某类书的起始编号；用 datetime 存登记日期能保留到时分秒，初始化脚本里甚至把 ‘2013-01-18 12:20’ 这种精确时间写进 regdate，说明设计者预期同一读者在同一天可能发生多次操作，光有日期不够区分先后。至于 readername varchar(9)、bookname varchar(30) 这类偏窄的长度，是课程设计里常见的拍脑袋取值，生产系统一般会给足冗余度。

2.3 建表 SQL 中的外键机制：数据库凭什么能挡住“不存在的分类”

看建表语句最能理解外键的工作机制。以下是对原脚本的精简版，保留了核心约束：

CREATE TABLE book_style ( bookstyleno varchar(30) PRIMARY KEY, -- 类别编号：业务主键 bookstyle varchar(30) -- 类别名称 ); CREATE TABLE system_books ( bookid varchar(20) PRIMARY KEY, -- 书籍编号：业务主键 bookname varchar(30) NOT NULL, bookstyleno varchar(30) NOT NULL, bookauthor varchar(30), bookpub varchar(30), bookpubdate datetime, bookindate datetime, isborrowed varchar(2), -- 状态标记：1=在库可借，0=已借出 FOREIGN KEY (bookstyleno) REFERENCES book_style(bookstyleno) ); CREATE TABLE system_readers ( readerid varchar(9) PRIMARY KEY, readername varchar(9) NOT NULL, readersex varchar(2) NOT NULL, readertype varchar(10), regdate datetime );

外键的机制说起来并不玄：往 system_books 插入一行时，数据库引擎要在 book_style 的主键索引里查一次 bookstyleno 是否存在，找不到就拒绝整条 INSERT。这背后是两张表之间的存在性承诺——父表的主键是子表数据的合法性依据。SQL Server 在执行这类检查时还会在父表对应行上持有共享锁，防止检查通过后、事务提交前，父行被并发删除，这也是为什么外键能挡住很多应用层挡不住的并发竞态。代价同样存在：每次插入子表都多一次索引查找，外键列最好有对应索引，好在原脚本的外键列大多同时也是主键或靠近主键，走了聚集索引，成本可控。

2.4 流水表的主键选择：用 bookid 当主键，一借一还的语义被写死

再看三张流水表的建表语句：

CREATE TABLE borrow_record ( bookid varchar(20) PRIMARY KEY, -- 一本书同一时刻只能有一条借出记录 readerid varchar(9), borrowdate datetime, FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) ); CREATE TABLE return_record ( bookid varchar(20) PRIMARY KEY, -- 一本书只能还一次 readerid varchar(9), returndate datetime, FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) ); CREATE TABLE reader_fee ( readerid varchar(9) NOT NULL, readername varchar(9) NOT NULL, -- 冗余读者姓名，直接展示罚款单 bookid varchar(20) PRIMARY KEY, bookname varchar(30) NOT NULL, -- 冗余书名，避免再 JOIN 图书表 bookfee varchar(30), -- 罚款金额，注意这里用了字符串 borrowdate datetime, FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) );

主键在这里悄悄承担了业务规则的执行者：borrow_record 以 bookid 为主键，意味着同一本书的借出记录在表里最多一行，数据库从物理上杜绝了“同一本书同时被借给两个人”。return_record 同理，一本书只有一次还书机会。这是典型的“约束即业务”：不需要应用层写 if 判断，重复插入直接撞主键唯一索引，报一个重复键错误。代价也很明显，后面避坑章会说，这种设计让续借、多次借还变得非常别扭，因为主键天然不允许第二次出现。至于 reader_fee 里冗余 readername 和 bookname，是典型的用空间换 JOIN 的思路，罚款单打印时单表就能出数据。

提示：主键约束在背地里干了两件事——建唯一索引并强制 NOT NULL。按主键过滤时数据库直接走聚集索引，这也是后面所有单表查询都能很快的原因。

3. isborrowed 状态同步：为什么宁可冗余一个标记位，也不愿意每次实时 JOIN

3.1 两条查询路径的对比：物化状态与临时计算的差别

要理解 isborrowed，先看“查可借书”的两种写法。方案 A 完全从流水表推导，不用任何状态字段：

SELECT b.bookid, b.bookname FROM system_books b WHERE NOT EXISTS ( SELECT 1 FROM borrow_record br LEFT JOIN return_record rr ON rr.bookid = br.bookid WHERE br.bookid = b.bookid AND rr.bookid IS NULL );

逻辑是这样：先在 borrow_record 里找这本书的借阅记录，再 LEFT JOIN return_record，如果某条借阅记录找不到对应的还书记录，说明这本书借出去还没还回来；NOT EXISTS 把这类书排除，剩下就是可借的。这套查询完全正确，但写起来绕，而且只要 borrow_record 或 return_record 数据量大，关联顺序和索引稍有偏差就容易慢。方案 B 是原系统实际采用的方式：

SELECT bookid, bookname FROM system_books WHERE isborrowed = '0';

一条 WHERE 完事。isborrowed 的本质是“物化状态”：把“这本书现在在不在馆”这个高频查询答案提前算好、存在行里，查询时不需要再通过两次 JOIN 推导当前状态。这是反规范化的典型动机——规范化的目标是消除冗余、保证事实单一来源，但查询当前状态需要组合多张流水表；状态标记把组合计算前移到写入阶段，读路径就变简单了。代价是写入路径必须负责维护这个副本，否则它就会说谎。理解了这一点，借书时为什么要先 insert 再 update，就成了顺理成章的事。

3.2 借书链路的两步 DML：INSERT 流水与 UPDATE 状态为什么必须成对出现

原脚本里借书的初始化数据是这么写的：往 borrow_record 插入借阅记录，同时把 system_books 的 isborrowed 从 1 更新成 0。把这两步放进一个事务里，就是完整的借书操作：

BEGIN TRAN; -- 把流水插入和状态翻转绑成一个原子操作 INSERT INTO borrow_record(bookid, readerid, borrowdate) VALUES('901', 'R001', '2013-06-01 09:00:00'); UPDATE system_books SET isborrowed = '0' WHERE bookid = '901' AND isborrowed = '1'; -- 带条件更新，相当于乐观锁 IF @@ROWCOUNT = 0 BEGIN ROLLBACK; RAISERROR('该书已被借出或状态异常', 16, 1); END ELSE COMMIT;

我一般会这么理解这里的 UPDATE 条件：AND isborrowed = '1'把一次普通更新变成了“比较并交换”。两个借书请求并发时，第一个请求把状态置 0 并影响一行，第二个请求的 UPDATE 匹配不到 isborrowed = '1' 的行，影响 0 行，事务回滚。没有这个条件，第二步就会无脑覆盖状态，把“已被借出”改回“在库也不是不可能”。原报告里的初始化脚本没有写事务，两步是分开执行的，课程演示时数据是人工写好的，顺序不会错乱；但真实业务里这两步中间一旦断电或者程序抛异常，就会出现“借阅流水写了，状态没翻”的脏数据。这也是后面避坑章会重点讲的现场。

3.3 还书链路与罚款计算：反向翻转状态，再用 DATEDIFF 算超期

还书是借书的逆操作：插入 return_record，同时把 isborrowed 从 0 翻回 1。罚款则在此基础上用借书日期与还书日期的差值减掉允许天数：

INSERT INTO return_record(bookid, readerid, returndate) VALUES('901', 'R001', '2013-06-15 10:00:00'); UPDATE system_books SET isborrowed = '1' WHERE bookid = '901' AND isborrowed = '0'; -- 超期罚款：按天计算 DECLARE @per_day_fee decimal(10,2) = 0.10; -- 每天罚金 DECLARE @allow_days int = 30; -- 允许借阅天数 DECLARE @over_days int; SELECT @over_days = DATEDIFF(day, br.borrowdate, rr.returndate) - @allow_days FROM borrow_record br JOIN return_record rr ON rr.bookid = br.bookid WHERE br.bookid = '901'; IF @over_days > 0 BEGIN INSERT INTO reader_fee(readerid, readername, bookid, bookname, bookfee, borrowdate) SELECT br.readerid, r.readername, br.bookid, b.bookname, CAST(@over_days * @per_day_fee AS varchar(30)), br.borrowdate FROM borrow_record br JOIN system_readers r ON r.readerid = br.readerid JOIN system_books b ON b.bookid = br.bookid WHERE br.bookid = '901'; END

DATEDIFF 返回两个日期之间跨越的边界数，这里按 day 直接得到天数差，减去 30 天允许期，大于 0 才产生罚款。注意罚款计算的先决条件是 return_record 里已经有还书时间，所以流程上必须先完成还书动作。这里的 bookfee 字段原设计是 varchar(30)，存数字字符串临时看没问题，但 SUM 聚合时会翻车，我在第 5 章详细拆。

3.4 为什么拆借阅、还书两张表，而不是一张带“已还标记”的流水表

还有一个容易忽略的设计点：借阅和还书被拆成了两张表，而不是经典的“一条借阅记录 + returndate 空值表示未还”。两种写法都能工作，取舍却不同。单表方案里，还书是 UPDATE 原来的借阅行，状态天然跟随同一行，查未还书只需要WHERE returndate IS NULL，逻辑紧凑；但缺点是还书动作会修改历史记录，借书那行的时间、操作者等审计信息可能被覆盖。双表方案把借书和还书都当成不可变事件，各追加一行，历史永远不被改写，配合 isborrowed 标记位，读路径的代价被转移到了写路径。这其实是“事件日志 + 状态快照”两层结构的一个雏形：borrow_record 和 return_record 是事件日志，isborrowed 是从日志推导出来的状态快照。课程设计里这种分层已经够用，也比单表方案更接近真实系统的思考方式。

4. 从初始化到统计报表：借书、还书、罚款这条链路在 SQL 里怎么走通

4.1 初始化顺序：为什么必须先插类别和读者，再插图书和借阅

数据库建好后第一件事是灌基础数据。原脚本的插入顺序看起来随意，其实被外键约束牢牢锁死，必须先插不依赖别人的表：

-- 第一步：类别表，不依赖任何表 INSERT INTO book_style(bookstyleno, bookstyle) VALUES ('1', '文学'); INSERT INTO book_style(bookstyleno, bookstyle) VALUES ('2', '科技'); -- 第二步：读者表 INSERT INTO system_readers(readerid, readername, readersex, readertype, regdate) VALUES('R001', '读者甲', '男', '学生', '2013-01-18 12:20'); -- 第三步：图书表，bookstyleno 必须已经在 book_style 中存在 INSERT INTO system_books(bookid, bookname, bookstyleno, bookauthor, bookpub, bookpubdate, bookindate, isborrowed) VALUES('901', '示例书A', '1', '作者甲', '某出版社', '2005-09-01', '2013-05-25', '1'); -- 第四步：借阅记录，readerid 和 bookid 都必须已存在 INSERT INTO borrow_record(bookid, readerid, borrowdate) VALUES('901', 'R001', '2013-06-01 12:20'); UPDATE system_books SET isborrowed = '0' WHERE bookid = '901';

四个步骤的依赖链很清楚：类别是图书的外键父表，读者和图书是借阅的外键父表。先插子表会直接报外键冲突，报错信息类似“INSERT 语句与 FOREIGN KEY 约束冲突”，它告诉你哪个父表缺数据，但不告诉你该去哪补数据，第一次实操的人常在这里发懵。要排查这种问题，按依赖顺序从父表开始逐张 SELECT COUNT(*)，哪张表缺哪张补，比盯着报错猜效率高得多。日期参数在这里统一写成 YYYY-MM-DD HH:MM:SS，SQL Server 会做隐式转换，把字符串解析成 datetime；如果写成格式不标准的日期，比如 YYYY/MM/DD 在某些语言环境下也能解析，但严谨的写法是用 CONVERT 显式指定格式。

4.2 单表查询到多表查询：哪些查询走标记位，哪些查询必须 JOIN

报告里演示的两条单表查询：

SELECT * FROM book_style; SELECT * FROM system_books;

在系统里，第一条查类别字典，第二条查全部图书。更贴近业务的查询是“未还书列表”，它必须从流水表出发，因为 isborrowed 只能告诉你“这本书被借出了”，不能告诉你“被谁借的、什么时候借的、超期没有”：

SELECT br.bookid, b.bookname, br.borrowdate FROM borrow_record br LEFT JOIN return_record rr ON rr.bookid = br.bookid JOIN system_books b ON b.bookid = br.bookid WHERE rr.bookid IS NULL;

这里 LEFT JOIN 的匹配键是 bookid，而 bookid 在 borrow_record 和 return_record 里都是主键，数据库能直接走聚集索引做关联，不会产生全表扫描。这条查询能成立，前提是“未还 = 有借无还”，也就是每一本被借出的书要么能在 return_record 里找到对应还书记录，要么保持借出状态。如果前面借书时漏了 INSERT 或 UPDATE，这个查询也会跟着出错，所以它同时也是一个很好的数据一致性探针。

4.3 统计查询：借阅排行榜和读者维度的聚合为什么绕不开流水表

报告的任务要求里有“书籍借阅情况统计或读者借阅情况统计”，这是 GROUP BY 的典型场景：

-- 书籍借阅排行榜：统计每本书被借了多少次 SELECT TOP 5 bookid, COUNT(*) AS borrow_times FROM borrow_record GROUP BY bookid ORDER BY borrow_times DESC; -- 读者维度：统计每个读者借过多少本 SELECT readerid, COUNT(*) AS total_borrow FROM borrow_record GROUP BY readerid;

为什么统计必须从 borrow_record 出发，而不能看 isborrowed？因为状态标记只保留“当前”结果，是最终一致性里的最终态快照，它回答“此刻谁借了什么”这种瞬时问题；统计要的是“历史上发生过多少次”，必须把每一笔流水都数一遍。COUNT(*) 按 group by 分组时，SQL Server 可以利用 borrow_record 主键上的索引做流式聚合，数据量不大时性能完全够。这类查询也解释了为什么流水表要保留全部历史，不能用 UPDATE 覆盖旧状态——一旦把借阅记录改成还书状态，所有历史统计瞬间失真。

4.4 关系代数与 SQL 的对应：报告里“查询描述”的逻辑骨架

课程设计报告要求每个查询先写关系代数，再写 SQL 实现。背后的用意是强迫你先想清楚逻辑再做语法表达：选择运算σ对应 WHERE 条件，投影运算π对应 SELECT 后面要哪几列，连接运算⋈对应 JOIN 的关联条件，分组聚合对应 GROUP BY。比如“查所有学生的借书证编号和姓名”，关系代数写π_readerid, readername (σ_readertype='学生'(system_readers))，SQL 就是SELECT readerid, readername FROM system_readers WHERE readertype = '学生'。关系代数不关心索引、不关心执行计划，它只描述“要什么”；SQL 还要回答“怎么取”，比如走哪个索引、用不用临时表。能把一个查询同时用两者表达，说明你既懂目标又懂路径，这是报告设计这套要求最实际的价值。

5. 避坑排查指南：主键冲突、状态翻转失败、金额字段翻车的五个现场

5.1 表名 book_sytle 与 book_style 混用：对象名无效

现象：按照报告里数据字典建了一张名为 book_sytle 的类别表，然后执行后文建表脚本，SQL Server 报“对象名 system_books 无效”或外键引用失败。原因：报告正文的这张表名写的是 book_sytle，而建表脚本和外键引用统一用的是 book_style，一个字母之差，两个对象根本对不上。解决：以建表 SQL 为准，把所有表名统一成 book_style；如果错误的表已经建了，先DROP TABLE book_sytle再重建；表多的时候用SELECT name FROM sys.tables核对实际存在的对象名，别靠肉眼猜。

5.2 isborrowed 的 1/0 语义反转：注释和实际行为打架

现象：数据字典里注释写着“是否被借出”，按这个理解，已借出的书 isborrowed 应该等于 1。但初始化脚本里所有图书 isborrowed 都是 1，借出之后反而 UPDATE 成 0。查询“可借书”时条件写isborrowed = 1，结果把已经借出去的书全部查了出来。原因：字段名义上是“是否被借出”，实际语义是“是否在馆可借”——1 表示在库，0 表示已借出，命名和注释都没有反映真实约定。解决：两条路选一条走死。要么把字段改成 is_available，1=在库可借；要么保留 isborrowed 但注释明确写“0=已借出，1=在库”，查询条件统一写成WHERE isborrowed = '0'。我一般建议多花十秒加一个 CHECK 约束CHECK (isborrowed IN ('0','1'))，至少把非法值挡在表外。

5.3 借书两步缺事务：INSERT 成功、UPDATE 失败，状态就永久说谎

现象：借书时只执行了 insert into borrow_record，update system_books 那一步因为手滑漏掉或报错没执行，界面上这本书仍然显示“在库”。另一个读者来借同一本书，borrow_record 主键冲突直接报重复键错误，用户看到的是莫名其妙的错误码，而不是“已被借出”。原因：insert 和 update 是两条独立的写操作，没有事务包裹就是两个原子点，任一点失败都会造成流水与状态不一致；主键约束挡住了第二次借阅，却把业务原因掩盖成了技术报错。解决：用BEGIN TRAN ... COMMIT把两步包起来，UPDATE 带isborrowed = '1'条件并检查@@ROWCOUNT，影响 0 行就回滚并抛业务异常；应用层单独捕获 2627 号重复键错误，翻译成“该书当前不可借”。这也是事务 ACID 里原子性最朴素的应用场景。

5.4 return_record 以 bookid 为主键：同一本书只能还一次

现象：第一次还书正常，第二次还同一本书时报告“违反了 PRIMARY KEY 约束”，连数据补录都做不了。原因：return_record 的主键是 bookid，bookid 在表里只能出现一次，这个约束预设“一本书这辈子只借出一次、只归还一次”，完全不支持续借、再次借出这类常见业务。一本书还回去之后又被借走，下次还书时就必然撞主键。解决：把 return_record 改成自增流水号做主键，id int IDENTITY(1,1) PRIMARY KEY，bookid 降级为普通列并建索引；还书前先查“这本书当前有没有未还的借阅记录”，有才允许还。borrow_record 靠近真实的设计也不是拿 bookid 当主键，而是加一个借阅流水号，bookid 靠唯一约束或应用层判断保证单本未还唯一。

5.5 罚款金额用 varchar 存储：ORDER BY 变字典序，SUM 直接报错

现象：汇总罚款总额时执行SELECT SUM(bookfee) FROM reader_fee，SQL Server 报“将 varchar 转换为数据类型 numeric 时失败”；不报错时ORDER BY bookfee排出来的是 10、100、11 这种字典序，不是数值序。原因：reader_fee 表里 bookfee 字段定义为 varchar(30)，字符串类型参与数值聚合时要么隐式转换失败，要么按字符排序规则比较。原因在于建表时没想清楚“金额是数值不是文本”。解决：字段类型改成decimal(10,2)，插入罚款时用 CAST/CONVERT 把计算出的数值显式转成 decimal；历史脏数据先UPDATE reader_fee SET bookfee = CAST(bookfee AS decimal(10,2))清洗，再改表结构。建表时多问一句“这一列会不会参与加减乘除”，能避开这类后期最难受的返工。

注意：varchar 存金额的隐患往往不在第一次插入，而在第一次做报表时集中爆发。所有“能显示”和“能计算”是两码事，字段类型先决定你能不能算。

6. 设计取舍：业务主键、冗余状态与系统长大之后的代价

这套系统的设计取舍值得单独拎出来看，因为它把数据库设计里三组经典矛盾压缩在一个很小的规模里。第一组是业务主键与自增代理主键。bookid、readerid 直接用业务编号，查询直观，关联时 SQL 一眼能看懂；但随着业务增长，业务编号可能面临重编码、前缀调整，一旦主键值要改，所有外键子表都会跟着承受级联检查的代价。生产系统更常见的做法是加一个自增的代理主键，业务编号做成普通唯一索引，两边的好处都占，代价是多一列、多一个索引，以及每一处 JOIN 都要稍微绕一下。

第二组是 isborrowed 这种状态标记与完全实时推导。标记位让“可借书列表”查询从多表 JOIN 变成单表等值过滤，但一致性要靠事务和严格的 DML 顺序来维持；实时推导没有冗余副本，永远一致，却把复杂度压在每次查询上。课程设计规模下，数据量几千行，两条路都能跑通；到十万册、百万流水的规模，标记位方案需要配合定时对账，实时推导方案需要精心设计索引和物化视图。没有绝对正确，只有你在“读性能和写复杂度的天平”上愿意压哪一边。

第三组是外键约束与应用层校验。外键把数据的合法性判断下沉到数据库，任何一条漏网 SQL 都写不进脏数据；但外键也带来锁竞争和级联路径，高并发写入场景下有人宁愿在应用层做校验，把数据库当存储容器。我的态度是：课设阶段、中小系统，外键是成本最低的防线，删掉它省下的那点性能，往往不够赔一次数据事故。

验证这套系统状态是否还自洽，可以用一条“对拍 SQL”把标记位和流水表互相对照：

SELECT b.bookid FROM system_books b LEFT JOIN ( SELECT bookid FROM borrow_record EXCEPT SELECT bookid FROM return_record ) unreturned ON unreturned.bookid = b.bookid WHERE b.isborrowed = '0' AND unreturned.bookid IS NULL;

它的含义是：找那些 isborrowed 标记为已借出、但在“未还集合”里却查不到对应记录的图书，找出来的行就是状态不一致的脏数据。这个查询在 SQL Server 上能用 EXCEPT，MySQL 上可以换 NOT EXISTS，逻辑等价。从那以后我每次做完借还书类的功能，都会强制把这条对拍 SQL 跑一遍，再顺手查一次 SUM(bookfee) 能不能正常聚合，多花十秒，少熬一个夜。希望帮到你。

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