不该。图书借阅是有限线性流转，用 status 字段+枚举值（如 'borrowed', 'returned'）足够，加状态机表会增加JOIN、降低更新同步性与性能；应使用 TINYINT/ENUM 类型、时间戳字段及复合索引优化。
借阅状态该不该单独建状态机表？
不该。图书借阅本质是“借出→归还→续借→逾期→注销”这类有限线性流转，用 status 字段 + 枚举值（如 'borrowed', 'returned', 'overdue'）足够，加状态机表反而让简单逻辑变重、JOIN 多、更新难同步。
常见错误现象：为“看起来规范”硬套工作流引擎思路，结果每次借书要插 2 行（主记录 + 状态日志），查当前借阅人还得 JOIN 状态表取最新一条，性能掉一截。
- 状态字段建议用
TINYINT或ENUM（MySQL 8.0+ 支持排序和约束），别用字符串——避免拼写错、索引效率低 - 必须留操作时间戳：
borrowed_at,returned_at,due_at，比纯状态字段更能支撑业务判断（比如“是否真逾期”得比due_at和当前时间） - 不要用触发器自动更新状态——容易和应用层逻辑冲突，调试时根本分不清谁改的
status
借阅记录表怎么防重复借、超限借？
靠唯一约束 + 应用层检查双保险，不能只信代码或只信数据库。
使用场景：同一读者对同一本书未归还前不能再借；读者总借阅数不能超 5 本（假设规则）。
- 加联合唯一索引：
UNIQUE KEY uk_reader_book_active (reader_id, book_id) WHERE status = 'borrowed'（MySQL 8.0+ 支持函数索引，否则用生成列或应用层保证） - 查当前借阅总数用
SELECT COUNT(*) FROM borrow_records WHERE reader_id = ? AND status = 'borrowed'，别在内存里计数——分布式部署下会错 - 插入前先
SELECT ... FOR UPDATE锁住该读者的活跃记录行（不是全表锁），再判断数量，否则并发高时可能超限
逾期判断该放数据库还是应用层？
数据库只存事实，判断逻辑放应用层。MySQL 的 NOW() 在从库可能有秒级延迟，且业务规则常变（比如寒暑假不计逾期），硬写进 SQL 会拖慢查询、难维护。
性能影响：如果在 WHERE 里写 NOW() > due_at 查所有逾期记录，索引基本失效（due_at 字段能用，但函数包裹后无法走范围扫描）。
- 把
due_at和status一起建复合索引：INDEX idx_status_due (status, due_at)，查status = 'borrowed' AND due_at 才高效 - 定时任务（如每小时）批量更新状态为
'overdue'，而不是实时查——避免高频SELECT ... WHERE due_at - 应用层做判断时，传入的是服务端时间（非数据库
NOW()），确保多实例时间一致
历史归还记录要不要删？
不要删。归还不是终点，而是审计起点——谁借的、啥时候还的、有没有损坏、是否逾期，都得可追溯。
容易踩的坑：为“清理数据”定期 DELETE FROM borrow_records WHERE status = 'returned'，结果丢了赔偿记录、统计报表崩了、财务对不上账。
- 加
is_archived字段替代物理删除，归还后设为1，查活跃借阅时加AND is_archived = 0 - 按年分区表（
PARTITION BY RANGE (YEAR(returned_at))），查近一年数据快，老数据归档也方便 - 备份策略要覆盖历史记录表——它比借阅中表还重要，出事第一个被查
状态字段的含义、时间字段的精度、并发下的数据一致性，这三处不抠清楚，后面加再多监控和日志都救不回错乱的借阅关系。
