2

列にハッシュ値の画像srcが格納され、そのハッシュ値がmicrotime（）から生成されるテーブルがあります。次に、ハッシュ値をデータベースに直接格納するか、画像名の派生元であるbigintmicrotimeを格納するかの2つの選択肢があります。 。これにより、データベースが高速になります。

4

2 に答える 2

1

これをあらゆる側面から分析して、どの速度障害が発生しているかを評価する必要があります。

私はいくつかの仮定をします：

  • このデータは識別子（主キー、一意キー、複合キー）として使用されます。
  • このデータは検索と結合に使用されます。
  • 60文字の16進エンコードデータの文字列を生成するSHA1などのハッシュアルゴリズムを使用しています（MD5は32文字の16進エンコードデータの文字列を生成します。使用している場合は、以下のすべてをMD5に適合させることができます）。
  • ハッシュの16進値をバイナリに変換して、必要なストレージを半分に減らし、比較速度を向上させることに関心があるかもしれません。

アプリケーション側での挿入と更新：

@Namphibianが述べたように、BIGINTの2つの操作と、CHARの3つの操作で構成されています。

しかし、私の意見では、速度の違いはそれほど大きくありません。10.000.000の連続計算を（whileループで）実行し、それらのベンチマークを実行して、それらの実際の違いを見つけることができます。

また、アプリケーションコードの速度の違いはユーザーに直線的に影響しますが、DBの速度の違いは、トラフィックが増加するとユーザーに非線形に影響します。これは、重複する書き込みが互いに待機し、一部の読み取りが書き込みの終了を待機する必要があるためです。

DB側での挿入と更新：

BIGINTの場合もCHAR（40）またはBINARY（20）の場合とほぼ同じです。これは、実際にディスクに書き込むのではなく、ディスクへのアクセスを待機するために、より深刻な時間が消費されるためです。

DB側での選択と参加：

これは、次の2つの理由から、CHAR（40）またはBINARY（20）と比較してBIGINTの方が常に高速です。

  • BIGINTは8バイトに格納され、CHAR（40）は40バイトに格納され、BINARY（20）は20バイトに格納されます。
  • BIGINTの連続的に増加する性質により、予測可能で、比較と並べ替えが容易になります。

次善のオプションはBINARY（20）です。これは、スペースを節約し、長さが短くなるため比較が容易になるためです。

BINARY（20）とCHAR（40）はどちらもハッシュメカニズムの結果であり、ランダム化されます。したがって、インデックス内のランダム化されたデータ（btreeインデックスの場合）はフェッチするためにより多くのツリートラバーサルを必要とするため、比較と並べ替えに平均して長い時間がかかります（iつまり、単一の値ではなく、複数の値のコンテキストで）。

于 2012-06-25T08:24:37.400 に答える
0

ここでは重要な科学的原則が適用される可能性があります。元のデータを失わないでください。あなたはそれが何のために必要かもしれないかを決して知りません。

于 2012-06-25T10:39:21.357 に答える