MongoDBのセカンダリインデックスサイズはプライマリキーサイズの影響を受けますか？
私が正しく理解していれば、MySQL InnoDBエンジンのセカンダリインデックスリーフノードは、テーブルのプライマリキー値を保持します（少なくとも一意のインデックスの場合）。
したがって、セカンダリインデックスで値を検索すると、2つのBTREEルックアップが発生します。1つはセカンダリインデックス用で、もう1つはクラスター化インデックス（主キーでクラスター化）用です。これは、主キーのサイズがすべてのセカンダリインデックスのサイズに影響することも意味します。
これはMongoDB WiredTigerセカンダリインデックスも機能しますか？またはMongoDBセカンダリインデックスはドキュメントが存在する物理ブロックへの参照を格納しますか？ （これがPostgresがインデックスを処理する方法だと思います）
私は正しく理解しています。MySQLInnoDBエンジンのセカンダリインデックスリーフノードは、テーブルのプライマリキー値を保持します（少なくとも一意のインデックスの場合）。
InnoDBテーブルには クラスター化インデックス があり、行のデータが格納される場所を決定します。 InnoDBテーブルのクラスター化インデックスは、PRIMARY KEY（設定されている場合）、すべてのキー列がNULLでない最初の一意のインデックス、または合成行ID値を含む非表示インデックスのいずれかです。セカンダリインデックスエントリには、レコードの場所のクラスタ化されたインデックスへの参照が含まれます。
これはMongoDBWiredTigerセカンダリインデックスもどのように機能しますか？*またはMongoDBセカンダリインデックスはドキュメントが存在する物理ブロックへの参照を格納しますか？
MongoDB（4.0以降）はクラスター化されたインデックスをサポートしていません。 WiredTigerストレージエンジンは、InnoDBで説明した3番目のオプションと同様のアプローチを使用します。64ビット整数である内部一意のRecordIDです。
WiredTigerストレージエンジンは現在、コレクションとインデックスごとに個別のファイルを使用しています。収集データ（collection-*.wt）内部RecordIDを使用してインデックスが作成されます。インデックス（index-*.wt）キーを関連するコレクションデータのRecordIDにマップします。これらの実装の詳細は、データのインデックス作成、クエリ、および操作のための一貫したエンドユーザーインターフェイスを提供するMongoDBAPIには関係ありません。ストレージエンジンは、データがディスク上およびメモリ内でどのように表されるかについて所有権を持っています。このアプローチは、InnoDB（エンドユーザーがMySQL APIを介して対話している）などの他のデータベースエンジンの内部で行われていることと類似しています。
主キーのサイズ（これは_id MongoDBのフィールド）は現在、WiredTigerのセカンダリインデックスのサイズに影響を与えません。
ちなみに、古い（そして非推奨の）MMAPv1 MongoDBストレージエンジンを使用している場合、データが存在するディスクの場所（ファイルとオフセット）への参照が保存されます。このアプローチの重大な欠点は、（ドキュメントの増大による）ストレージ内のドキュメントの移動でも、すべてのセカンダリインデックスを更新する必要があることです。 WiredTigerは、関連付けられたフィールド値が変更された場合にのみセカンダリインデックスを更新する必要があります。