5〜7個のmysqlテーブルから頻繁に更新される同じデータセットを選択する必要がある、要求の厳しいmysqlクエリがいくつかあります。「選択」操作は、CUD よりも少し多くなります。
テーブルまたはマテリアライズド ビューを作成して、要求の厳しいすべての列を他のテーブルから収集し、さまざまなテーブルへの全体的なクエリ時間を短縮してパフォーマンスを向上させることを考えています。
そのテーブルを作成すると、他のテーブルが更新されるたびに追加の挿入/更新/削除操作が必要になる場合があります。
マテリアライズドビューを作成すると、パフォーマンスが大幅に向上するか心配です。他のテーブルのデータが頻繁に変更されるためです。ほとんどの場合、ビューを選択する前に毎回最初にビューを作成する必要があります。
何か案は？たとえば、キャッシュする方法は？私ができる他の追加の対策は？
パフォーマンスを向上させるために、要求の厳しいすべての列を他のテーブルから収集するテーブルまたはビューを作成することを考えています。
ほとんどの場合、ビューを選択する前に毎回最初にビューを作成する必要があります。
ビューはクエリに他なりません。したがって、ビューから選択するクエリを作成するか、単純な sql を実行するだけかは問題ではありません。パフォーマンスは同じになります。
キャッシュする方法
キャッシングは非常に複雑で具体的な問題です。したがって、万能薬はなく、決定を下すには、より詳細な情報を提供する必要があります。
「具体化されたビュー」の概念に沿って考えているように思えます。
Mysql はこれの実装を提供していませんが、多かれ少なかれ洗練された方法でシミュレートできます(私はPostgresql で後で同様のことを行います - レポートで頻繁に使用される複雑なパラメータ化されていないクエリに便利です。完全に最新のデータでなくても許容できます)。
後述するように、パフォーマンスを向上させるための万能薬はありません。そして、上で述べたこととは異なり、インデックスはDB のパフォーマンスにとって最も重要なことではありません。データベースを正しくセットアップすることが重要です。データベースが大きくなるにつれて、DB 構成がパフォーマンスを支配するようになる可能性があります。これに関して最も重要なのは、適切に構成されたディスク サブシステムを用意することです。大規模なデータベースは、ディスクとの間でデータを転送する速度によってパフォーマンスが常に制限されるためです。
特定の質問に関しては、クエリを介して具体化されたビューを偽造することが役立つ場合とそうでない場合があります。挿入と更新のパフォーマンスが低下する可能性がありますが、選択のパフォーマンスが向上する可能性があります。必要に応じてオンデマンドで「ビュー」を作成しても、遅いクエリを実行して作成する必要があるため、何もしません。MySQL は具体化されたビューを直接サポートしていないため、標準のビューは何もしません。
詳細がなければ、より良いヘルプを提供することは不可能です。