回答:
ハッシュテーブルの主キーによってのみ要素にアクセスできます。これは、より高速な（ツリーアルゴリズムと比べてO(1)の代わりにlog(n)）、しかし、あなたは（範囲を選択することができない間にすべてのものをxしてy）。ツリーアルゴリズムはこれをサポートしてLog(n)いますが、ハッシュインデックスはテーブル全体をスキャンする可能性がありますO(n)。また、ハッシュインデックスの一定のオーバーヘッドは通常、大きくなります（これはシータ記法には影響しませんが、それでも存在します）。また、ツリーアルゴリズムは通常、維持、データの増加、スケーリングなどが容易です。
ハッシュインデックスは事前定義されたハッシュサイズで機能するため、オブジェクトが格納される「バケット」ができます。これらのオブジェクトは、このパーティション内で本当に適切なオブジェクトを見つけるために再びループされます。
したがって、サイズが小さい場合、小さい要素のオーバーヘッドが大きくなり、サイズが大きいと、さらにスキャンが行われます。
今日のハッシュテーブルアルゴリズムは通常スケーリングしますが、スケーリングは非効率的です。
確かにスケーラブルなハッシュアルゴリズムがあります。それがどのように機能するか私に尋ねないでください-それは私にとっても謎です。AFAIKは、再ハッシュが容易ではないスケーラブルなレプリケーションから進化しました。
そのRUSH - R eplication U nder S calable H ashingと呼ばれるため、これらのアルゴリズムはRUSHアルゴリズムと呼ばれます。
ただし、インデックスがハッシュサイズと比較して許容できるサイズを超え、インデックス全体を再構築する必要がある場合があります。通常、これは問題ではありませんが、巨大で巨大なデータベースの場合、これには数日かかることがあります。
ツリーアルゴリズムのトレードオフは小さく、それらはほとんどすべてのユースケースに適しているため、デフォルトです。
ただし、非常に正確なユースケースがあり、何が必要で何が必要かを正確に知っている場合は、インデックスのハッシュを利用できます。
実際、MySQLは次のリンクに従って、ハッシュテーブルとbツリーの両方の種類のインデックスを使用しているようです。
Bツリーおよびハッシュテーブルを使用しての違いは前者が使用できるようにすることである列比較を =、>、> =、<、<=、またはオペレータとの間には、後者の中に使用される使用式でのみのために =または<=>演算子を使用する等価比較。
ハッシュテーブルの時間の複雑さは、十分なサイズのハッシュテーブルに対してのみ一定です（データを保持するのに十分なバケットが必要です）。データベーステーブルのサイズは事前にわからないため、ハッシュテーブルから最適なパフォーマンスを得るために、テーブルを時々再ハッシュする必要があります。再ハッシュも高価です。
ハッシュマップもスケーリングされず、マップ全体を再ハッシュする必要がある場合は高額になる可能性があると思います。