选型时把“能支持多少人”抛给供应商，往往得到一个模糊的范围。与其问能撑多少人，不如把业务翻译成三类可以算出来的量：写入峰值、结算批量、查询并发。

【写入峰值：关键在集中在几分钟内，不在总人数】

举个估算的例子。某3000人规模的厂区，早班打卡集中在7:50到8:10这20分钟，假设九成员工在这段时间完成，就是2700条写入，平均每秒二点二五条，看着不高。但如果三班倒交接、门禁、食堂消费同时压在同一套后台，瞬时压力会成倍上升。三万人的园区，同一时间窗口的写入是前者的十倍。

算清这个数，才知道接口要不要做异步队列、要不要批量提交、设备端要不要先本地缓存再整包上传。很多所谓“卡顿”，其实是接口一条一条走同步事务造成的。

【结算批量：月末那几小时才是真正的考验】

日常写入是细水长流，月结算是一次性把大量明细按规则跑一遍。按每人每天4条记录、每月22个工作日估算，三万人规模一个月约264万条考勤明细。全量重算时，如果逐条去查班次表、节假日表、加班审批单，等于几百万次小查询，跑一整夜并不奇怪。

可行的做法有几条：把班次、节假日、审批结果预先加载进内存，按人分批处理，结果批量写回；上月明细做归档，冷热数据分离，让参与计算的数据集保持在可控范围；重算只针对异常人员和变更规则覆盖的区间，不做全量。

【查询并发：员工看工资那几天，压力不在考勤表】

微信端工资查询开放的几天，请求特征和考勤完全不同：读多写少、每次查询带权限校验、对响应时间敏感。如果工资查询直接压在业务主库上，很容易和月末结算抢资源。把查询类请求做读写分离或走缓存，把权限校验前置到接口层，是常见的处理方式。人事管理软件系统在设计阶段就要把这类读请求和写请求分开考虑，否则越到后期越难拆。

【表结构设计决定了后面能走多远】

考勤明细表的字段设计、索引选择、分表策略，在需求阶段就该定下来。按月份分表、按员工编号做前缀索引是常见组合；如果把十几个查询条件全部建上索引，写入性能会明显下降。这些取舍没有通用答案，得看实际的查询习惯。深圳市英普瑞科技有限公司在做定制项目时，通常先梳理客户日常用到的查询场景清单，再决定索引与分表方案，避免数据量涨上来之后再返工改表。

把“能撑多少人”拆成写入峰值、结算批量、查询并发三个问题，架构讨论才有落点。真正决定使用体验的，往往不是硬件参数，而是需求阶段就定下来的那几张表。