特定の非正規化により、特定のシナリオでパフォーマンスが向上しますか？
フィールドのあるテーブルがあるとします| a | b | c | d | ... | z |これには数百万のレコードが含まれており、1日に数百万のクエリを処理します。また、フィールドzは、5つの可能な値の1つである可能性のあるパラメータのidを保持します。このパラメータは決して新しい値を取得します。
私が必要としているのは、この表のselectの可能な最大速度とパフォーマンスです。他のすべてのクエリタイプのパフォーマンスは重要ではありません。ディスク容量もそれほど重要ではありません。
非常に重要な点は、各selectクエリで常にzの値を1つだけ値（例：where z = 1）また、selectクエリを使用して、常に他のフィールドでレコードをフィルタリングし、いくつかの結合を行います。
問題は、テーブルをselectの5つの可能な値の1つにそれぞれ対応する5つのテーブルに分割することで、zのパフォーマンスが向上するかどうかです。 MySQLデータベースを使用しますが、一般的な回答があれば聞きたいです。
問題は、テーブルを5つの可能なzの値の1つにそれぞれ対応する5つのテーブルに分割することで、selectのパフォーマンスが向上するかどうかです。
はい、ここでパーティショニングを使用できます。パーティションの削除が開始されます。パーティションは、主要なインデックス列として機能します。
これにより、次の点に到達します。すべてのインデックスの先頭の列としてzを追加するだけです。常にzでフィルタリングするため（等式述語を使用）、これは役に立ちます。 （ただし、インデックスがID列のインデックスのように一意である場合を除く）。
ここではいつものようにデータベースで少し一般化していますが、必ずzのフィルタリングをインデックスに追加してください。
もちろん、インデックスをカバーするなど、他の手法も適用されます。
ここでは、5つのテーブルを作成したり、パーティションを使用したりする必要はないと思います。ただし、zを保存する必要がなくなったため、パフォーマンスが数パーセント向上する可能性があることがわかります。
アプリが十分な負荷を生成しているため、負荷の数パーセントが問題になる場合は、私の定義ではサーバーが過負荷になっています。それでも、開発と保守のコストの増加を気にしないのであれば、試してみる価値があります。