数据多了以后，三种应付办法都不好用
加机器、删旧单、忍着慢——每一种都在把问题推到明年。
报表一开就转圈
第三年的库存明细账、门店日销售汇总越查越慢，给出的建议是加内存换机器，钱花了行数还在那儿。
这套做法：把时间轴切开：日常查询只落在最近一年的运行库上，历史数据不陪跑。
旧单要么删要么不敢动
有人每年清一次旧单，去年合同要核对时翻不出来；有人一直不清，把库越拖越沉。
这套做法：不删也不挤：一年以前的数据自动进历史库，要翻回客户端翻，日常不受它影响。
查不到就以为丢了
财务在网页版搜去年那张单没有结果，第一反应是数据丢了，接着找实施、找老板、找供应商。
这套做法：提前把分工写进流程：历史库只有客户端可达，界面上确实不给查，这是设计不是故障。
这件事只有三条要记住
分层是系统自己做的；人要安排的，是谁去查旧账、用哪一端。
| 在哪一层 | 怎么落 | 说明与界面上看得到的 |
|---|---|---|
| 日常业务落在运行库 | 收银、订货、调拨、盘点、凭证这些当天要反复查的单据，全在运行库里跑 | 例：门店交班、库存明细账、应付帐款总览这类天天开的页面，读的都是运行库这一层 |
| 一年以前的数据自动进历史库 | 按年自动滚动归档，日常不需要管理员手动去点 | 例：现在是 2026 年 10 月，一年以前生效的单据落在历史库那一层，运行库只留最近这段 |
| 谁查旧账，用哪一端 | 历史库只有客户端可达，网页版查不到 | 例：核去年的月饼券销售、对三年前的供应商往来，让财务在客户端上查，别在网页版翻 |
| 权限还是同一套 | 能进哪个页面、能按哪个按钮，两端通用 | 例：不想让门店碰旧账，收的是这个账号的角色与端，而不是给历史库单独上一把锁 |
| 跨年报表先确认口径 | 做"今年对去年同月"这类对比前，先确认这张报表读哪一层 | 例：只读运行库的报表，去年那段可能是空的；要合并两层的口径，先和实施同事对齐 |
要坦白的一件：归档按自然日还是按会计期切、历史库的界面长什么样、能不能从历史库导出，本轮都没有取到证据，所以这三处只写"以实机为准"，不编。
一次"去年的单怎么找"的走法
四步，走的是同一套账，差别只在换一端。
| 第几步 | 做什么 | 在哪一层 | 结果 |
|---|---|---|---|
| 1 | 在网页版按单据号搜去年的销售单 | 运行库 | 没有结果——它不在这一层 |
| 2 | 先确认这张单确实超过一年 | — | 超过一年即已进历史库 |
| 3 | 换到客户端，按同一条件再查 | 历史库 | 查到，金额与单据状态都还在 |
| 4 | 要留档就在客户端打印或导出 | 历史库 | 日常报表仍留在运行库，不受影响 |
为什么不干脆做一张"全历史"大报表
听起来省事，代价是所有日常查询都要背着几年的行数跑。分层的思路是反过来的：让最常看的那一段快起来，很少碰的那部分挪走，需要时再取。
- 第 1 步那个"没有结果"最容易被当成丢数据。它不是丢了，是在另一层库里，换一端就有。
- 日常九成的查询根本不碰历史库，这正是运行库能一直轻的原因——查询快不是靠加机器，是靠不陪跑。
- 如果某个岗位经常要翻旧账（年结对账、加盟结算、大客户年审），就给他固定一台客户端，而不是每次临时借机器。
这三种情形最吃这一层设计
账开到第几年、旧单翻得多不多，直接决定要不要给某个岗位固定一台客户端。
开到第三年、报表开始变慢
先把日常查询压回运行库这一层，跨年对比另走客户端。多数"要加机器"的需求，到这一步就不用花钱了。
有年结对账任务的财务
年结要翻去年甚至前年的单，这是最该固定客户端的岗位——权限沿用同一套角色即可。
加盟与直营混跑、合同期长
加盟结算与供货价核对经常要回往年的约定，旧账留在历史库里，比删掉再补录体面得多。
这一页最怕被读成两句话，所以逐条写清
一句是"旧账还在"，一句是"网页版查不到"——两句都得说，只说半句一定出事。
- 网页版查不到历史库，要提前写进流程。不写清楚，第一次翻旧账的人一定以为数据丢了，然后是一通排查。
- 归档时点与界面本轮未取证。"一年以前"按自然日还是按会计期切、历史库入口长什么样、能不能导出，都以实机为准；这一页按产品口径写，等客户端截图到位再补真实界面。
- 历史库不是备份。它是同一份数据的另一层存放，救的是"还查得到"；整库出事仍然只能靠备份与恢复，见"数据安全管家"那一页最后一条。
- 跨年报表要先问口径。凡是"今年对去年"的对比，先确认这张报表读的是哪一层，别拿运行库的结果当全量。
分两层放，和"一张大表装下所有年份"
同样是三年老店的数据，两种安排下每天的查询体验。
| 比什么 | 运行库与历史库分离 | 一张大表装下所有年份 |
|---|---|---|
| 日常查询负担 | 只压最近一年的数据 | 几年的行数一起背着跑 |
| 旧账可得性 | 在历史库，客户端可达 | 随手能查，但每次都慢 |
| 删旧单的压力 | 不需要删 | 常被逼着删，或另建一套账 |
| 报表口径 | 要区分运行库与历史库 | 口径统一，代价是慢 |
| 运维动作 | 按年自动滚动 | 手动清理、换库、加机器 |
四步把"旧账"这件事安排下去
分层本身不用配，要配的是人和口径。
列出"谁要翻旧账"
年结对账、加盟结算、大客户年审这三个岗位最需要，其他部门基本用不到历史库。
给这些岗位固定客户端
不要临时借机器；权限沿用同一套角色与机构，不需要另配一套。
在流程里写一句话
"一年以前的单去客户端查"——这一句能省掉一次"数据丢了"的报警。
跨年报表先确认口径
上线对比报表前和实施同事确认它读哪一层，再决定要不要把两层的结果合并。
关于运行库与历史库，常被问到的六件事
不是删除，是换一层存放。日常查询不再带着它们跑，需要时在客户端仍然查得到，单据状态与金额都还在。
本页能确认的是分工本身：网页版面向日常运行库，历史库从客户端可达。这样安排换来的是日常查询只压最近一年的数据；要核更具体的实现原因，请找实施同事。
按年自动滚动，日常不需要管理员手动点。至于精确到哪天切、能不能提前归档某段期间，本轮没有取证，以实机为准。
本轮没有取到"按单据例外"的开关证据，所以不承诺。如果某段期间要长期随手查，请先与实施同事确认做法。
这一层的界面本轮没有取证，不承诺导出；先在客户端确认能查到，再谈打印与导出。
闸门管的是删错了能不能收场、谁能把数据带走；分层管的是账越久越厚时日常还快不快。两件事都在为"三年后还敢用"服务，建议连着看。
库分两层之外，端也要分清楚
旧账在哪一端查、日常在哪个端跑，是同一张分工表上的两行。
系统架构的八项机制，一项一页
这一页讲的是其中一项。想知道日常业务还靠哪些底层机制兜住，直接切过去。