nimrodm Asked: 2019-05-30 12:13:23 +0800 CST2019-05-30 12:13:23 +0800 CST 2019-05-30 12:13:23 +0800 CST MongoDB二级索引大小受主键大小影响吗？ 772 如果我理解正确，MySQL InnoDB 引擎中的二级索引叶节点保存表主键值（至少对于唯一索引）。 因此，在二级索引中查找一个值会导致两个 BTREE 查找：一个用于二级索引，另一个用于聚集索引（聚集在主键上）。这也意味着主键大小会影响所有二级索引的大小。 这也是 MongoDB WiredTiger 二级索引的工作方式吗？或者 MongoDB 二级索引是否存储对文档所在物理块的引用？（我相信这就是 Postgres 处理索引的方式） mongodb wiredtiger 1 个回答 Voted Best Answer Stennie 2019-05-31T00:10:08+08:002019-05-31T00:10:08+08:00 我理解正确，MySQL InnoDB 引擎中的二级索引叶节点保存表主键值（至少对于唯一索引）。 InnoDB 表有一个聚集索引，它决定了行数据的存储位置。InnoDB 表的聚集索引是 PRIMARY KEY（如果设置），所有键列 NOT NULL 的第一个唯一索引，或者包含合成行 ID 值的隐藏索引。二级索引条目将包括对记录位置的聚集索引的引用。 这也是 MongoDB WiredTiger 二级索引的工作方式吗？* 或者 MongoDB 二级索引是否存储对文档所在物理块的引用？ MongoDB（从 4.0 开始）不支持聚集索引。WiredTiger 存储引擎使用类似于为 InnoDB 描述的第三个选项的方法：内部唯一 RecordID，它是一个 64 位整数。 WiredTiger 存储引擎目前为每个集合和索引使用单独的文件。集合数据 ( collection-*.wt) 使用内部 RecordID 进行索引；索引 ( index-*.wt) 将键映射到相关集合数据中的 RecordID。这些实现细节与 MongoDB API 无关，后者为索引、查询和操作数据提供了一致的最终用户界面。存储引擎对数据在磁盘和内存中的表示方式拥有所有权。该方法类似于 InnoDB 等其他数据库引擎（最终用户通过 MySQL API 进行交互）的幕后情况。 您的主键（将是_idMongoDB 中的字段）的大小目前对 WiredTiger 中二级索引的大小没有影响。 顺便说一句，如果您碰巧使用的是较旧（且已弃用）的 MMAPv1 MongoDB 存储引擎，它会存储对数据所在磁盘位置（文件和偏移量）的引用。这种方法的一个显着缺点是存储中的文档移动（由于文档增长）还需要更新所有二级索引。WiredTiger 只需要在关联字段值更改时更新二级索引。
InnoDB 表有一个聚集索引，它决定了行数据的存储位置。InnoDB 表的聚集索引是 PRIMARY KEY（如果设置），所有键列 NOT NULL 的第一个唯一索引，或者包含合成行 ID 值的隐藏索引。二级索引条目将包括对记录位置的聚集索引的引用。
MongoDB（从 4.0 开始）不支持聚集索引。WiredTiger 存储引擎使用类似于为 InnoDB 描述的第三个选项的方法：内部唯一 RecordID，它是一个 64 位整数。
WiredTiger 存储引擎目前为每个集合和索引使用单独的文件。集合数据 (
collection-*.wt) 使用内部 RecordID 进行索引；索引 (index-*.wt) 将键映射到相关集合数据中的 RecordID。这些实现细节与 MongoDB API 无关，后者为索引、查询和操作数据提供了一致的最终用户界面。存储引擎对数据在磁盘和内存中的表示方式拥有所有权。该方法类似于 InnoDB 等其他数据库引擎（最终用户通过 MySQL API 进行交互）的幕后情况。您的主键（将是
_idMongoDB 中的字段）的大小目前对 WiredTiger 中二级索引的大小没有影响。顺便说一句，如果您碰巧使用的是较旧（且已弃用）的 MMAPv1 MongoDB 存储引擎，它会存储对数据所在磁盘位置（文件和偏移量）的引用。这种方法的一个显着缺点是存储中的文档移动（由于文档增长）还需要更新所有二级索引。WiredTiger 只需要在关联字段值更改时更新二级索引。