Neki 跑到每秒 1.18 亿查询：这次测试没有副本，也没有写入
据 PlanetScale 公布的 Neki 性能测试，团队在 512 个分片、1.22 PiB 数据上持续 16 分钟实现约 1.185 亿 QPS。测试采用单分片主键点查，不含写入、联接或跨分片查询，且各分片只有主库，没有副本。
作者：林岚｜OC 开发者生态编辑
据 PlanetScale 公布的 Neki 性能测试，团队在 512 个分片、1.22 PiB 数据上持续 16 分钟实现约 1.185 亿 QPS。测试采用单分片主键点查，不含写入、联接或跨分片查询，且各分片只有主库，没有副本。
一句话结论：这个结果展示的是特定只读工作负载下的横向吞吐能力，不能直接换算成生产数据库的综合性能或可用性。
昨天说能分片，今天测的是哪一部分
此前 OC 介绍 Neki 的平台预览时，重点是路由、分片与运维结构。新公布的测试提供了吞吐数据，但它不是把完整生产配置原样搬上跑分台。
这一点尤其值得注意：日常架构讨论里的副本承担容灾与可用性职责，而本次测试明确没有副本，也没有在测量窗口内进行故障切换。因此，“数据库能够处理这些读请求”与“数据库能在同样负载下完成故障恢复”，仍是两道不同问题。
把这两篇材料接起来看，合理的理解不是前后矛盾，而是配置服务于不同目的。架构说明描述产品如何组织，性能测试则需要逐项交代实际启用了什么。
一次请求只找一个分片，为什么很关键
这次工作负载按主键取一行，每个请求只落到一个分片。增加分片，就能让更多互不干扰的请求同时运行。这正是容易观察横向扩展能力的场景，也能检查路由层是否很快成为集中瓶颈。
但真实业务里的一个页面，可能同时读取账户、订单、权限和推荐结果。若这些数据不在同一个分片，请求就需要协调多个节点，再汇总答案。排序、聚合和跨分片联接还可能进一步改变网络与内存开销。
所以，业务方不应先问“能不能买到一亿 QPS”，而应先问自己的查询有多大比例能保持单分片。分片键选择与数据共置，决定了有多少请求能走上这条短路径。
一个巨大的总数背后还有资源清单
厂商披露，测试使用了 480 个路由实例和 512 个数据库主节点。总吞吐很高，但它不是单机成绩，也不是一个小规模集群通过升级软件就能直接获得的提升。
容量规划至少需要两张表：一张记录吞吐和延迟，另一张记录机器、网络、存储及运维成本。没有后者，就难以判断某个方案是更经济，还是只是用了更多资源。
同样，测试中的持续时间也有意义。十几分钟可以观察一次负载窗口，却不能替代长时间运行中的备份、维护、数据增长、节点替换和热点变化。一个系统跑得快，与它几个月后仍然容易管理，不能只由同一张成绩单回答。
延迟要问是在什么位置测的
报告分别列出路由端和客户端的 p99 延迟，两者并不相同。客户端看到的是更靠近使用者体验的路径，路由侧则更便于观察服务内部处理。
这提醒读者，比较数据库延迟必须对齐测量点。把一家服务端数字与另一家的客户端数字摆在一起，很容易制造不存在的差距。
错误也应进入容量讨论。即使失败比例很低，在很大的请求总量下，绝对数量仍可能给重试、日志和告警带来压力。应用需要区分可重试错误与业务失败，不能把接近满分的成功率理解为“不需要恢复设计”。
关键事实
- 测试为厂商披露，持续窗口为 16 分钟。
- 512 个分片、480 个路由实例，约 1.185 亿 QPS。
- 单分片主键点查，无写入、联接及跨分片请求。
- 主库单独运行，无副本，测量期间没有故障切换。
OC 判断
这是一份有价值的扩展性结果，因为厂商把重要限制写了出来。真正的下一步，是把副本、混合读写、热点和故障场景加回去，再看自己的工作负载，而不是删除这些限定后转发一个大数字。
为什么重要
- 对开发者：数据共置会决定查询能否保持简单。
- 对采购方：性能与资源成本需要同时对齐。
- 对运维：吞吐测试不替代恢复与长期稳定性验证。
评论
围绕这篇文章补充信息、提出问题或分享观察。