MySQLでインデックス付きビューを持つことは可能ですか？
私は 2005年のMySQLフォーラムへの投稿 を見つけましたが、それより新しいものはありません。それに基づいて、それは不可能です。しかし、多くは3〜4年で変わる可能性があります。
私が探しているのは、ビューにインデックスを付ける方法ですが、表示されるテーブルにはインデックスを付けないままにしておきます。インデックス作成は書き込みプロセスに悪影響を及ぼし、このテーブルは非常に頻繁に書き込まれます（インデックス作成によりすべてがクロールされるまで遅くなります）。ただし、このインデックスの欠如により、クエリが非常に遅くなります。
MySQLがマテリアライズドビューをサポートしているとは思いませんが、これはあなたが必要とするものですが、とにかくこの状況では役に立ちません。インデックスがビューにあるか、基になるテーブルにあるかに関係なく、基になるテーブルの更新中のある時点で、インデックスを書き込んで更新する必要があるため、書き込み速度の問題が発生します。
あなたの最善の策は、おそらく定期的に更新されるサマリーテーブルを作成することでしょう。
トランザクション処理データを分析処理データから抽象化し、それらの両方が独自の要件を満たすように専門化できるようにすることを検討しましたか？
基本的な考え方は、定期的に変更されるデータの1つのバージョンがあるということです。これはトランザクション処理側であり、書き込み操作が高速になるように、重い正規化と軽いインデックスが必要です。データの2番目のバージョンは、分析処理用に構造化されており、正規化の度合いが低く、高速レポート作成操作のためにより多くのインデックスが作成される傾向があります。
分析処理を中心に構造化されたデータは、通常、データウェアハウジングのキューブ方法論を中心に構築され、キューブの側面を表すファクトテーブルとキューブのエッジを表すディメンションテーブルで構成されます。
Flexviews は、基になるテーブルへの変更を追跡し、マテリアライズドビューとして機能するテーブルを更新することにより、MySQLのマテリアライズドビューをサポートします。このアプローチは、ビューでサポートされるSQLが少し制限されていることを意味します（変更ロギングルーチンは、変更を追跡する必要のあるテーブルを把握する必要があるため）。 。
インデックス付きビューが1つだけ必要ですか？インデックスが1つだけのテーブルへの書き込みが混乱を招く可能性はほとんどありません。主キーはありませんか？
各レコードが大きい場合は、短くする方法を考え出すことでパフォーマンスを向上させることができます。または、必要なインデックスの長さを短くしてください。
これが書き込み専用のテーブルである場合（つまり、更新を行う必要がない場合）、MySQLでアーカイブを開始したり、レコード（およびインデックスキー）を削除したりして、インデックスの作成（再利用）を開始する必要があります。新しいインデックス値を追加するだけでなく、削除されたキーのスロット。直感に反しますが、この場合はテーブルを大きくすることをお勧めします。