番号库的检索性能优化
直接答案：本页围绕检索性能优化按定义、判定逐节说明。
检索性能主要受索引类型与深度影响。本文比对 B-Tree、Hash 与倒排三种取舍，给出"索引深度对命中延迟"的示例，配合索引层次的划分方法与编号结构分段。 同族里可先看库层索引性能切定义脉络与库层索引性能切主词定义脉络互为参照, 跨族则以番号大全的分类维度设计与番号核验流程与工作单做外部锚点。
只讨论公开命名的检索性能建模；示例数值取自模拟环境。
三种索引的适配
| 索引类型 | 点查 | 范围查 | 聚合 | 典型用途 |
|---|---|---|---|---|
| B-Tree | 优 | 优 | 中 | canonical 唯一索引与前缀范围扫描 |
| Hash | 极优 | 不支持 | 差 | 只按 canonical 精确点查的高并发场景 |
| 倒排 | 中 | 中 | 优 | 按命名族多值聚合与统计 |
三种可共存：主键走 B-Tree，命名族聚合走倒排，高并发点查加 Hash 缓存。B-Tree 通用Hash 极致点查倒排适合聚合
跨呈现层邻接读物(续)
索引性能取舍需要参考社区置顶层的压力：社区置顶层对索引性能压力的样本反馈。
跨呈现层邻接读物
索引性能取舍要参考聚合站入口分片压力：聚合站入口分片对索引性能的压力回压。
索引深度与命中延迟
三万条样本估算，B-Tree 树深 2→4 层点查延迟约 40→90 微秒；6 层约 180 微秒。延迟接近线性，内存占用近似指数。
点查为主时深度≤3；范围扫描为主时可放宽 4-5 层。点查主线：深度 ≤ 3
内存与索引的平衡
B-Tree 整棵常驻内存延迟降到 20 微秒，代价是内存翻倍。折中只常驻上两层，第三层走 SSD，延迟约 50 微秒。字段模型见元数据字段速览。
与番号大全清单的差别
性能优化的量化收益
三万条样本估算，主键索引深度 4→3 层可让点查 P95 延迟 120→60 微秒，聚合吞吐提升约 1.4 倍。
关于检索性能的常见问题
Hash 索引能替代 B-Tree 吗
不能。Hash 不支持范围查与排序，只适合精确点查。
倒排索引会不会太重
示例里倒排存储开销约为主表的 1.4 倍，可接受。
索引重建有窗口要求吗
在线重建可分批；离线重建约需 12 分钟，安排在低峰期。
边界与局限
只覆盖建模的常见取舍，不涉及具体产品与执行计划优化。
相关阅读：提升检索速度的技巧集，可对照本节内容进一步展开。
参考资料
- 参照 SQL 标准的索引类型与执行语义
- 参照 B-Tree 与 Hash 索引的经典教材
- 参照 ISO 2108 编号命名规范中的分段建议