3

処理するアイテムのキューとして機能するテーブルがあります。このテーブルには、レコードがまだアクティブであるかどうかを示す0または1を含むことができるステータス列があります。テーブルには現在最大400万行があり、急速に拡大します。

行の分布は、ステータス= 0の場合は約5%、ステータス= 1の場合は95%です。通常のクエリでは、ステータス=0のレコードのみが検索されます。

テーブルが大きくなるにつれて、クエリは遅くなり始めています。これは、カーディナリティが低すぎるため、MySQLオプティマイザがステータス列のインデックスを使用していないためです。

ステータス列でテーブルを2つのパーティションに分割することを検討しています。パーティションプルーニングを利用できるため、通常、分析する必要があるのは全レコードの5%のみであると考えられます。アーカイブ上の理由から、status=1のレコードを保持します。

私の質問は、このアプローチが私が探している望ましい効果をもたらすのか、それともネガティブがメリットを上回るのかということです。行をstatus=0からstatus=1に更新すると、パフォーマンスに問題が発生しますか?

4

1 に答える 1

1

ステータス列の更新のパフォーマンスが懸念される場合は、アーカイブレコードのみを格納する別のテーブルを作成し、サーバーの休止時間中に一定期間ごとにアーカイブレコードを元のテーブルからこのアーカイブテーブルに移動するようにスケジュールするのはどうでしょうか。

このように、最初の移行後、「アクティブな」テーブルがはるかに小さくなり、ステータスを「0」から「1」に変更するI/Oの速度がエンドユーザーによって認識されなくなります。

于 2012-07-05T07:11:43.877 に答える