diff --git a/docs/develop/总体设计文档.md b/docs/develop/总体设计文档.md
index 537cca4..e169d3c 100644
--- a/docs/develop/总体设计文档.md
+++ b/docs/develop/总体设计文档.md
@@ -23,6 +23,9 @@
 - 进程内部使用同一个文件描述符时，可以并发地调用读取函数，但是会自动相互阻塞
 - 当使用不同的文件描述符时，并发调用读取函数时不会自动相互阻塞，如果并发读取的区域重叠，会有安全性问题
 
+![pic](https://cloud.zymsite.ink/f/8vCd/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%202023-11-29%20102719.png)
+一次IO的固定开销差不多相当于1e5条CPU指令或1e4次基本操作，以及相当于读入一块100KB~1MB的连续空间，可以考虑把分块链表的块级索引集中到开头的一个大块里。
+
 ~~因此我不太打算碰文件系统~~
 
 #### 数据库设计方案
@@ -32,7 +35,7 @@
 ###### 底层实现
 通过B+树或一个有序的块状链表实现一个键值数据库，相当于`std::multimap`，一个键值数据库实例拥有恰好一个文件
 ###### 逻辑实现
-数据库的一条记录有主键（应当是唯一的）、副键和数据构成，从主键到数据建立multimap，从副键到主键建立multimap，一个数据库实例拥有恰好两个文件。
+数据库的一条记录有主键（应当是唯一的）、副键和数据构成，从主键到数据建立multimap，从副键到主键建立multimap，一个数据库实例拥有恰好两个文件，一个数据库可以有多个Sheet，用于逻辑上存储不同的表。
 
 ##### 文件访问与缓存
 memoryriver类维护一个缓存，简单地缓存高频访问和连续访问；键值数据库根据逻辑缓存最近访问和高频访问；数据库层不设缓存。
@@ -56,6 +59,8 @@ memoryriver类维护一个缓存，简单地缓存高频访问和连续访问；
 
 ## 前端
 ~~不清楚有没有时间写~~。WebUI，采用`Node.JS`+`Socket.IO`，~~不打算弄得很好看，不打算支持响应式设计~~，支持图形化操作面板和“云命令行”。和interactive模式一样，单个会话的操作支持逻辑上并发（上一操作未结束可以发出下一操作）但后端实际上是串行的。对于通讯中断、偶发的服务器未响应，只保证不会彻底崩掉，不保证出问题的业务能恢复。会话管理方面，只负责信息准确投送。
+
+~~不考虑卡死的情况，数据库卡死了也拿它没办法，引擎部分不死循环就不会卡死~~，只支持重置session。
 ### 服务端
 提供会话管理。虽然有log，但后端的响应只会发送一次，用于防止客户端掉线的缓存由服务端维护。
 ### 客户端