解读

国内一线互联网与金融客户在使用 CouchDB 做“离线优先”或“边缘节点”方案时，普遍会开启 partitioned:true 以把单库拆成 4 096 个逻辑分区。面试官问“视图索引文件如何按分区前缀隔离”，实质想验证两点：

1. 你是否知道 .view 文件在磁盘上的真实路径；
2. 你是否明白 分区键（partition key）→ 分区哈希 → 索引前缀 的完整映射链，以及这条链如何防止跨分区扫描。
   答不到“文件名里带分区前缀”这一层，基本会被判定为“只用过，没看过源码”。

知识点

1. 分区哈希算法：CouchDB 3.x 沿用 4 096 固定桶，对 partition_key 做 crc32(partition_key) & 0xFFF 得到 0–4095 的整数。
2. 视图索引文件名规则：
   {db_name}.{shard_suffix}/{design_doc_id}/{view_name}.{partition_hash}.view
   其中 partition_hash 用三位十六进制小写补齐，例如 000 1f3 fff。
3. 磁盘目录结构：
   data/shards/{0000-1fff}/{db_name}.{shard_suffix}/…
   每个物理分片目录下，再按 partition_hash 拆出独立的 .view 文件，实现“同一片内再隔离”。
4. 查询隔离机制：
   带 ?partition=xxx 时，CouchDB 直接定位到 partition_hash.view，不会打开其他 4 095 个文件；全局查询则走 COUCHDB-3647 优化，并行扫描所需分区文件，仍保持隔离。
5. compaction 粒度：分区级 .view 文件可单独 compact，不会触发全库视图重写，大幅降低 IO 抖动，这是国内大容量账单类业务最看重的运维指标。

答案

启用 partitioned:true 后，CouchDB 在生成视图索引时，会把每个分区键经 crc32 哈希到 0–4095 的整数，再格式化为三位十六进制字符串作为 分区前缀。
最终产生的索引文件路径为：
data/shards/{range}/{db.name}.{timestamp}/{design_doc}/{view_name}.{partition_prefix}.view
同一设计文档下，每个分区前缀对应独立的 .view 文件，磁盘层面天然隔离；查询时通过分区前缀直接定位文件，避免跨分区扫描，从而保证线性扩展性与 IO 隔离性。

拓展思考

1. 如果业务需要 动态调整分区数量（例如从 4 096 扩到 16 384），CouchDB 当前版本需离线重做整库，分区算法硬编码在头部 header 中，无法在线变更；国内大厂通常提前按 16 384 预分区，牺牲一点元数据内存换未来十年可扩展。
2. 多主复制场景下，同一分区前缀的 .view 文件在不同节点可能因冲突文档产生不同哈希，CouchDB 通过 视图增量合并（view merge） 解决，但合并代价与分区数成正比，分区粒度越细，合并 CPU 越高，面试可借此引出“如何权衡分区数与复制延迟”。
3. 国内监管要求 “账簿不可篡改”，部分券商把 .view 文件连同 .couch 一起做 WORM 存储；由于分区前缀隔离，只需锁定对应 {partition_prefix}.view 即可实现 分区级冻结，大幅降低合规存储成本。