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