11

400 万行の MyISAM テーブルを持つ MySQL データベースがあります。このテーブルを週に 1 回、約 2000 の新しい行で更新します。更新後、次のようにテーブルを変更します。

ALTER TABLE x ORDER BY PK DESC

主キー フィールドの降順でテーブルを並べ替えます。これにより、私の開発マシン (3 GB メモリの Windows) では問題が発生しませんでした。実動 Linux サーバー (512MB の RAM を使用し、毎回約 6 分で結果のソート済みテーブルを達成する) で 3 回成功裏に試しましたが、最後に試したときは、約 30 分後にクエリを停止して、クエリを再構築する必要がありました。バックアップからのデータベース。

512MB のサーバーは、このような大きなテーブルでのその変更ステートメントに対処できますか? ALTER TABLE コマンドを実行するために一時テーブルが作成されることを読みました。

質問: この変更コマンドは安全に実行できますか? テーブルの変更に予想される時間は?

4

5 に答える 5

3

読んだばかりのように、ALTER TABLE ... ORDER BY ...クエリは特定のシナリオでパフォーマンスを向上させるのに役立ちます。PK インデックスがこれに役立たないことに驚いています。しかし、MySQL のドキュメントから、 InnoDBインデックスを使用しているようです。ただし、InnoDB は MyISAM と同様に遅くなる傾向があります。つまり、InnoDB を使用すると、テーブルの順序を変更する必要はありませんが、MyISAM の驚異的な速度は失われます。それでも一見の価値があるかもしれません。

あなたが問題を説明する方法は、メモリにロードされたデータが多すぎるようです (おそらくスワッピングが行われているのでしょうか?)。メモリ使用量を監視することで簡単に確認できます。私はMySQLをよく知らないので、なんとも言えません。

一方、あなたの問題は非常に別の場所にあると思います.4Mioを超える行を含むテーブルを持つデータベースサーバーとして、RAMが512メガしかないマシンを使用しています...そして、非常にメモリを大量に消費するそのマシンのテーブル全体に対する操作。それには 512Meg では十分ではないようです。

ここで私が見ているより根本的な問題は、実稼働環境とは非常に異なる環境で開発 (そしておそらくテストも) を行っているということです。あなたが説明している種類の問題は予想されるものです。開発マシンには、本番マシンの 6 倍のメモリがあります。私は、プロセッサもはるかに高速であると安全に言うことができると信じています. その場合、本番サイトを模倣した仮想マシンを作成することをお勧めします。そうすれば、本番サイトを中断することなく、プロジェクトを簡単にテストできます。

于 2009-08-31T20:31:29.243 に答える
1

主キーは auto_increment ですか? その場合、ALTER TABLE ... ORDER BY を実行しても、すべてが順番に挿入されるため、何も改善されません。

(削除が多い場合を除きます)

于 2009-09-01T18:43:21.643 に答える
0

ORDER BYInnoDB を使用している場合は、挿入後またはクエリ時に明示的に実行する必要はありません。MySQL 5.0 のマニュアルによると、InnoDB はすでにクエリ結果の主キーの順序付けをデフォルトに設定しています。

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

UPDATE代わりに、MyISAM テーブルはデフォルトで挿入順にレコードを返します。これは、クエリを使用して行をインプレースで変更するのではなく、テーブルに追加するだけの場合にも同様に機能する可能性があります。

于 2009-09-01T00:35:25.527 に答える