長い文字列を検索するSQLパフォーマンス

長い文字列をハッシュして、ストア（キャッシュ、またはデータベース）内で検索するトークンを作成するというアイデアは良いものです。私はこれが非常に大きな弦に対して、そして大量の環境の中で行われるのを見てきました、そしてそれは素晴らしい働きをします。

「このアプリケーションにはどのハッシュを使用しますか？」

データを暗号化するためにハッシュするのではなく、より長い値を検索するためのキーとして使用するトークンを作成するためにハッシュするので、暗号化（ハッシュ）アルゴリズムは実際には重要ではないと思います。したがって、ハッシュアルゴリズムの選択は、速度に基づいて行う必要があります。

「コードでハッシュを計算しますか、それともデータベースに処理させますか？」

それが私のプロジェクトの場合、アプリレイヤーでハッシュを実行し、それをパススルーしてストア内（キャッシュ、次にデータベース）を検索します。

「データベースに長い文字列を保存/検索するための根本的に異なるアプローチはありますか？」

私が述べたように、あなたの特定の目的のために、あなたの提案された解決策は良いものだと思います。

表の推奨事項（説明のみ）：

user

id int（11）unsigned not null
name_first varchar（100）not null

user_agent_history

user_id int（11）unsigned not null
agent_hash varchar（255）はnullではありません

エージェント

    agent_hash  varchar（255）はnullではありません
 ブラウザ varchar（100）はnullではありません
 エージェント nullではないテキスト
 
 
 スキーマに関するいくつかの注意事項：
   
 OPからは、ユーザーが職場でFirefoxを使用している可能性があるため、ユーザーとエージェントの間にM：Mの関係が必要であるように思われますが、自宅でIE9に切り替える可能性があります。したがって、ピボットテーブルが必要です。
 
  
  agent_hash に使用されるvarchar（255） 議論の余地があります。 MySQL 提案
 ハッシュを格納するためにvarbinary列タイプを使用します。その中にはいくつかのタイプがあります。
 
  
  agent_hashを作成することもお勧めします 主キー、または少なくとも列にUNIQUE制約を追加します。