北京
面对“从一对多关系中筛选出孩子满足条件、再按父亲属性排序分页”这样的需求，许多开发者第一反应是写个 JOIN，然后头疼性能。而 MongoDB 文档模型下的多键索引，为此提供了一种很直观的实现路径。
MongoDB 的多键索引可以把父文档里内嵌的子文档数组字段，和父文档自身的字段，一并放进一个复合索引里。比如，这两个字段的组合索引：子文档的 child_value 和父文档的 parent_value。这样一来，那些先按子文档某个值过滤、再对父文档排序、最后取前 N 条结果的查询，就可以完全走索引覆盖。
这里有两个很容易被忽略的关键语义。第一，这种查询返回的是“至少有一个孩子符合条件”的父文档集合，返回的是去重后的父亲，而不是父亲-孩子对。这和关系型数据库做父子表 JOIN，或 MongoDB 聚合管道里用 $unwind 展开数组再匹配，是根本不同的逻辑——后者会每个符合条件的子女都生成一行。多键索引的谓词，本质上做的是存在性测试。
第二，索引条目的数量等于父文档中 不重复 的孩子字段值数量，而不是孩子文档的总数。如果一个父亲有两个孩子，孩子的 child_value 都是 0.9，那么这个父亲在索引中只产生一条（0.9, parent_value）的索引项。这能减少索引膨胀，但也意味着当我们以子值的精确查找去定位父记录时，索引的组织方式对基数很敏感。
理解了这套机制，再看关系型数据库，比如 PostgreSQL，就想把类似思路带过去。目前没有一模一样的多键索引，但可以通过反范式化的方式来模拟：要么在“多方”子表上冗余储存父级的排序/过滤字段，要么在“一方”父表上聚合存储一组合格子记录的摘要信息。同时，依赖级联外键或触发器保证数据一致性，再配合 B-tree、GIN、甚至专用的 RUM 索引，来支撑效率更高的过滤与排序分页。
这种跨模型的思路切换，与其说是技术堆砌，不如说是在帮我们更本质地理解“一对多关系查询”到底想要什么：不是连接，不是展开，而是一次对父实体的存在性判定和有序检索。想透这一点，以后在设计 API 返回值、缓存结构，甚至前端列表渲染的时候，都能少踩不少坑。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
