系统架构会不会因为数据量大就越用越慢？

架构层面的事实是这些：

按租户隔离：SAAS 端的业务表通过路由按客户分配到各自的租户数据库，不是所有客户挤在一张表里；单据模型直接映射到 SQL Server 的业务表。
列表统一分页：后台列表页使用统一的分页组件，不一次性把全表拉到前端。
重逻辑下推数据库：记账、BOM 多层展开、成本结转等由存储过程执行，例如多级 BOM 展开、结转记账都有独立的存储过程。
门店端本地缓存：收银端把基础资料放本机缓存，断网时照常点单，网络恢复后补传单据。
大数据自动分离：安仕达特有的大数据自动分离技术，每天自动补传最新数据到历史数据库，再把古早的营业数据从运行库分离出去，运行库长期保持轻量；查询历史大数据也不会影响当前业务的操作。

至于「快不快」，这取决于账套数据量、服务器规格和网络环境，不做笼统比较。签约前建议用客户自己的数据量在测试账套上实测，我们配合压测。

这样设计的好处

拿客户近 6～12 个月的真实数据量在测试账套跑一遍：最大单店的日结、跨年度的销售流水查询、月结成本结转三个动作各计时一次。这三项覆盖了日常最重的负载，比抽象谈并发数更有意义。