最近、私はアプリの開発を依頼されました。このアプリは、基本的にデータベース全体で1つのメインの単一テーブルを操作に使用します。
10進数、int、varchar、date、floatなどのさまざまなタイプの約20列が必要です。ある時点で、テーブルには数千の行（3〜5k）が含まれるようになります。
アプリには、各列の基準を組み合わせてレコードを選択する機能が必要です。たとえば、日付の間、大きい、小さい、等しいなどです。基本的に、目的の結果を確認するには、多くのwhere句を組み合わせます。
だから私の質問は、私は場所を組み合わせてアプリを作る方法を知っているので、最良のアプローチは何ですか？つまり、MySQLは、3kレコードがあり、15個のWHERE句を使用してSELECTクエリを実行したときに、速度が低下しないほど十分に優れているということですか？1kレコードを超えるデータベースを使用したことがないため、これにMySQLを使用する必要があるかどうかはわかりません。また、それが重要な場合は、サーバー言語としてPHPを使用します。
あなたはONEwhere節の条件について話している。
リレーショナルデータベースの場合、3000行はごくわずかです。これらは通常、はるかに大きくなります（300万以上など）
1つのテーブルに20列あるのではないかと心配しています。これは正規化の問題のように聞こえます。
適切なインデックスを含む、データベースの構造が明確に定義されているため、15の条件があっても、3kレコードは何もありません。インデックスがなくても、レコードが非常に少ない場合、パフォーマンスに影響が出るかどうかは疑わしいです。
ただし、将来の計画を立て、クエリを調べて、将来の苦痛を軽減するために、この段階で実行できるテーブルの最適化があるかどうかを確認します。誰が知っている、今日は3kの記録、来年は30m。
データベース内の3000レコードは何もありません。15を使用しても、パフォーマンスの問題は発生しませんWHERE。
MySQLそして、PHPうまく仕事をします。
私はあなたの膨大な量の列についてもっと心配するでしょう。たぶん、あなたはあなたがデータベースを尊重していることを確認するためにこの記事normal formsを見る必要があります、
あなたのプロジェクトのために頑張ってください。
3〜5K行の単一のテーブルのクエリは特に集中的になるとは思いません。MySQLは、このような問題に簡単に対処できるはずです。これが「チョークポイント」である場合は、多くのインデックスを追加して選択を高速化できますが、これにより、挿入や編集などが遅くなります。また、多数の異なる行をクエリする場合、これはお勧めできません。
行数が非常に少ないので、パフォーマンスの問題は発生しないと思います。それでも、OR演算子の使用と、where句の列のインデックスを注意深く見ることができます。
インデックス、インデックス、インデックス！
多くの異なる列をチェックする必要がある場合は、使用するロジックをフラット化してみてください。いずれの場合も、チェックした列に適切なインデックスを設定していることを確認してください。列ごとのインデックスではなく、定期的に使用されるすべての列に対する1つのインデックス。