-1

f1 と f2 などの 2 つの unsigned int フィールドで構成される MySQL MYISAM テーブル (tbl など) があります。f2 にインデックスがあり、テーブルが非常に大きい (約 320,000,000 行以上)。このテーブルを定期的に (1 週間に約 100,000 行で) 更新し、ORDER BY (リアルタイム クエリでは非常に時間がかかる) を実行せずにこのテーブルを検索できるようにするために、テーブルを物理的に ORDER します。行を取得する方法に応じて。

そこで、ALTER TABLE tbl ORDER BY f1 DESC を実行します。（サーバー上にテーブルのコピー用の十分な物理スペースがあることはわかっています。）この操作中に一時テーブルが作成され、SELECT ステートメントが現在の行に影響を与えないことを読みました。

ただし、これは事実ではなく、ALTER テーブルと同時に発生するテーブルの SELECT ステートメントがブロックされ、終了しないことを経験しました。ALTER TABLE tbl が完了すると (本番サーバーで約 40 分)、tbl の SELECT ステートメントが再び正常に実行されます。

「ALTER table tbl ORDER BY f1 DESC」が他のクライアントによる tbl のクエリをブロックしているように見える理由はありますか?

4

1 に答える 1

0

テーブルを変更すると、常にテーブルのロックが取得され、SELECT の実行が妨げられます。

ALTER TABLEでそれができることさえ知らなかったことを管理します。

テーブルから何を得ようとしていますか？たとえば、特定の範囲内のすべてのレコード? 3 億 2000 万行は些細な数ではありません。私はあなたに私の腸の反応を与えます：

  1. InnoDB に切り替えます (#2 を許可し、トランザクションも提供しますが、#2 がないとパフォーマンスが低下する可能性があります)
  2. テーブルを分割します (いくつかのわずかに小さいテーブルのように機能させます)。
  3. 「ワーキング セット」テーブルと「履歴」テーブルを持ち、基本的に手動でパーティション分割するなど、再設計を検討してください。通常、最近挿入されたデータを探す場合、これは (パーティショニングと共に) 非常に役立ちます。ルックアップが均等に分散されている場合、これはおそらく違いはありません。
  4. 組み合わせて選択を絞り込むために使用できる新しい列を追加することを検討してください (日付で検索する代わりに、日付と顧客 ID で検索します)

あなたが何を保存しているのか私にはわからないので、これらのいくつか (#4 など) は当てはまらないかもしれません。

あなたが試すことができる他のいくつかのことがあります。OPTIMIZE TABLE は役立つかもしれませんが、時間はかかりませんが、私はそれを疑っています。内部的には、少なくとも InnoDB 側では、ダンプ/リロードとして実装されていると思います。

于 2010-12-18T00:12:54.230 に答える