次のフィールドを持つデータベーステーブル tblDetails があります。
itemID(int)(プライマリ)、itemCode(varchar)、itemName(varchar)、itemDescription(varchar)
現在、このテーブルには 50,000 を超える行があり、増加し続けています。ユーザーが itemCode を入力すると、クエリはテーブル全体を調べて、ユーザーが入力した itemCode が有効かどうかを確認する必要があります。したがって、私の懸念は、行数が増えるにつれてデータベースを検索するのにかかる時間です。
データベースを検索するより良い方法はありますか? より良いデータベース設計はありますか? 50,000 行のクエリを実行するには、どのくらいの時間 (約) がかかりますか?
提案してください。
にインデックスを設定するitemCodeと、その列の検索は線形ではなくなります。
使用しているデータベースが何であれ、そのインデックス付きの列を検索するには、バランスの取れたツリーのアプローチを取る必要があります。
にインデックスを配置する必要があると他の人はすでに説明していますitemCode。検索にかかる時間に答えさせてください。50000 値の B ツリー インデックスはおそらく約 3 レベルの深さになるため、メモリ内の関連ノード。安価な機械式ドライブでも 1 秒あたり約 100 回の読み取りができるため、検索には約 1/30 秒かかります。
とはいえ、それは最悪のシナリオです。関連するページがキャッシュされると、基本的に瞬時に 0 回のディスク読み取りで検索できる可能性があります。
ところで、50000 はデータベースのコンテキストでは非常に小さいです。適切なインデックス作成により、桁違いに大量の非常に高速な検索を実行できるようになります。5000000 の値の B ツリーは4 レベル程度の深さ、 500000000の値の深さは 5 レベルなどです (数値の例、YMMV)。これは対数依存性です。つまり、要素の数が増えるよりも検索の速度が遅くなります。
このトピックの詳細については、Anatomy of an SQL Index を読むことを強くお勧めします。
itemCode にインデックスを作成します。itemCode がテーブルに対して一意である場合は、それを主キーにします。クラスター化されたインデックスが取得され、アクセスがはるかに高速になります。