Enjoy Coding!

文章给出基于 LlamaIndex 构建本地 Markdown 文档问答的最小可行系统，分初始化设置、文档加载、向量索引构建、查询引擎创建和查询验证五步。初始化通过 Settings 全局配置 LLM 与嵌入模型，嵌入模型适合中文检索且可在 CPU 运行；文档加载精确读取 Markdown；索引构建自动完成切分、嵌入和内存存储；查询引擎封装检索与响应合成，可查看提示词；最后调用查询打印结果，验证端到端流程。读者可快速搭建可调试的 RAG 原型，并按需替换切分器、向量存储或嵌入模型。

文章用LangChain按四步实现RAG：数据准备、索引建立、检索优化、生成集成。先加载环境变量与中文嵌入模型，再用TextLoader读文档，用RecursiveCharacterTextSplitter默认参数分块，块大小4000、重叠200、保留分隔符。再以BAAI/bge-small-zh-v1.5生成归一化向量，存入InMemoryVectorStore。查询用similarity_search取k=3，以双换行拼接上下文。最后用ChatPromptTemplate要求仅凭上下文回答，信息不足则告知，调用ChatDeepSeek生成答案。读者可搭建可查询自有文档的RAG应用。

使用 Windows 11 电脑在 16GB 内存重启后占用近半的情况下，作者尝试了两种内存清理方法。通过 PCL2 启动器的“内存优化”按钮，内存占用从 6.9GB（45%）降至 3.4GB（22%），可用内存增至 11.9GB；重启后改用微软 RAMMap 工具，清理后占用同样降至 3.4GB，可用内存约 11.8GB。总结认为，PCL 操作简单、效果即时，适合普通用户；RAMMap 界面专业但清理能力较强，无需深入理解也能使用。内存占用过高时，使用一键清理工具即可有效释放数 GB 空间，满足日常使用需求。

本系列终章以借书和还书操作为例，阐述跨表事务的原子性是如何成为数据层闭环的最后拼图。借书须在同一个异步会话内，将图书状态改为“借出”并新增借阅记录，通过一次 `await db.commit()` 提交，避免图书被标记借出却缺失记录的不一致状态；还书同样需原子性地填充归还时间并复位图书状态。文章定义了 `Borrow` 模型与借还 DAO 事务实现，并点明高并发下需用 `SELECT FOR UPDATE` 行锁、时间字段统一使用 UTC 及软删除过滤等避坑要点。全文回顾了异步栈下四条一致规律：DAO 函数皆为 `async def`、Engine 应用级单例、Session 请求级作用域、事务边界显式控制，并将第 03 章至第 19 章的 CRUD 主干与跨表事务收束为完整的数据层闭环。

本文阐述在图书管理API中采用软删除方案，将删除操作转换为UPDATE语句，在deleted_at列写入UTC时间戳而非物理删除，以实现数据可逆恢复与审计完整。所有面向用户的查询必须在DAO层统一附加deleted_at IS NULL过滤，确保已删除行对业务透明，避免幽灵数据。删除时使用SQLAlchemy Core的update，根据rowcount判断资源是否存在或已被删除，统一抛出NotFoundError并返回404。为提升性能，建立(deleted_at,id)复合索引，使未删除记录的过滤与排序均能高效利用索引。此外，特别强调了应用层生成时间戳的语义优势、全局查询过滤的一致性，以及唯一索引冲突和定期清理墓碑行等注意事项。

文章介绍如何使用SQLAlchemy Core层的乐观锁机制解决并发更新冲突。核心方案是在数据表中增加`version`列，更新时通过`UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?`语句，利用数据库原子性地检测版本冲突。关键在于`version`的自增必须使用SQL表达式而非Python预计算值，以确保并发安全。DAO层执行更新语句后，通过检查`result.rowcount`判断操作结果：若为1则提交事务并返回最新数据；若为0则抛出`OptimisticLockError`异常，统一映射为HTTP 409冲突响应。此方法不区分记录不存在与版本不匹配。整体流程采用Core层`update()`直接构造语句，绕过ORM身份映射，事务边界清晰，适合按条件更新和乐观锁场景。

本文讲解基于SQLAlchemy异步ORM实现数据新增的核心流程，即`POST /books`的改造。关键是将Python对象持久化为数据库行的三步操作：`db.add(book)`为同步API，仅将对象注册至Session内存集合，不产生I/O；`await db.commit()`为异步协程，实际触发flush生成INSERT语句并提交事务，同时回填自增主键；`await db.refresh(book)`按需异步拉取数据库端生成的默认值。事务边界由依赖注入`get_async_db`与DAO内显式`commit`共同控制，异常路径需显式`await db.rollback()`或依赖上下文管理器自动回滚，以确保连接可用。

本文介绍了在FastAPI中将图书列表接口从全表查询升级为支持按作者、状态、关键词过滤以及分页与聚合的完整异步查询方案。核心思路是引入DAO层隔离路由与ORM，路由仅负责参数校验和调用，DAO使用SQLAlchemy 2.x的`select`惰性组合`where`条件（等值、`ilike`模糊匹配、`in_`集合过滤），并通过`func.count`直接进行数据库聚合统计，以`ORDER BY`加`offset/limit`实现分页。针对深页性能问题，预留了基于主键索引的键集分页演进空间。文中还强调了LIKE转义、空条件处理、事务一致性快照等实践细节，为后续增删改奠定结构基础。

本文将路由层的占位端点改造为基于异步SQLAlchemy ORM的真实MySQL查询。核心机制是通过`Depends(get_async_db)`按请求作用域注入`AsyncSession`，路由处理函数只需`await db.execute(select(Book))`即可完成查询，结果通过`scalars()`映射为ORM实例并序列化输出。整个过程严格遵循一次请求一个Session、业务代码不直接持有Engine的设计原则，Session在响应后自动关闭并归还连接池，保障事务边界与资源释放。由此，`GET /books`和`GET /books/{book_id}`真正打到MySQL，实现了从同步占位到异步真实查询的关键跨越，也为后续的过滤、分页及DAO层职责划分奠定了基础。

本文介绍了在 SQLAlchemy 2.x 中通过声明式基类 `DeclarativeBase`、`Mapped` 类型注解和 `mapped_column` 将 Python 类映射为 MySQL 表的核心做法。`ForeignKey` 在数据库层建立外键约束，`relationship` 则提供 ORM 层的对象导航，二者职责不同但协同工作。建表时需在启动流程中导入模型包以注册元数据，再通过 `engine.begin()` 获取异步连接，利用 `conn.run_sync(Base.metadata.create_all)` 桥接同步 DDL 操作。文章强调 `create_all` 仅适用于开发期快速建库，不能替代生产环境的迁移工具；枚举列变更需执行 DDL 迁移，级联删除应谨慎使用，并需主动使用预加载避免隐性 N+1 查询。生产环境应借助 Alembic 管理异步数据库迁移。