私は数百万行のテーブルを持っています。クライアントのhundresがこのテーブルに同時にアクセスしています。それぞれ一意的な行が20個あり、最後に行を配置する必要があります。複数のクライアントに一意の結果を同時に提供
私のセットアップは次のとおりです。
表構造：
id | last_access | reserved_id | [Data columns]
id + last_access is indexed
私は以下を使用し20の一意の行を選択する：
UPDATE "table" SET "reserved" = 'client-id_timestamp' WHERE "reserved" = ''ORDER BY "last_access" ASC LIMIT 20
この更新クエリが非常に悪いパフォーマンスが賢明である、ですなぜ私は尋ねる：
私の特定の要件のためのより良い解決策はありますか？おそらく別のテーブル構造ですか？
last_accessは日付列ですか？整数値（1970-01-01からの秒数）で表現すると、ソートが高速になる場合があります。
「予約済み」フィールドを変更した後でテーブルを再インデックスする必要があるため、2番目のパフォーマンスの問題が発生することがあります。その列から索引を削除すると、パフォーマンスが向上する可能性があります。検索に時間がかかりますが、より高価な再インデックスが式から外されます。
MySQL 5.6.3以降を使用している場合は、クエリでEXPLAINを実行して、どの部分が最も長くかかるかを調べることができます。
実際には列のインデックスを削除し、パフォーマンスの問題を修正しました。このため、ありがとうございます！ 私はまだ、このシナリオをどのように処理するかについて、より良い解決策があるべきだと思いますか？ 行数が増えるほどパフォーマンスが悪化しています。 – Jeppe
もっと詳しく説明しようと思っているかもしれません。なぜあなたは最後のアクセスで注文する必要がありますか？なぜ20を制限するのですか？データ列を別のテーブルに入れて、このテーブルを最小限に保つことが役立つかもしれません。 さらに短いテーブル（100k行）を保存することもできます。オブジェクトにアクセスすると、その行がこの「キャッシュ」テーブルに挿入/更新され、ある時間間隔で古いエントリが削除されるプルーニング・メカニズムがあります。 –
インデックスを再作成しないでください。索引の値を変更するため索引を更新するのはコストがかかりますが、表全体を再索引付けする方がコストがかかります。 –
引用符ではなく列名の前後にバッククワースを使用します。引用符は文字列です。 –
これは単なる例ですが、とにかく書き留めました。 – Jeppe