OPTIMIZE TABLE tbl_nameMySQLサーバーでクエリを実行することで得られる利点（実際に実用的）を教えてください。

これを一度確認したところ、これを実行した後、フラグメントの再配置などが原因で次のDBヒットに時間がかかる可能性があることがわかりましたが、その後のヒットではパフォーマンスが表示され、クエリキャッシュがこのトリックを実行するかどうかわかりません最適化または最適化のみでこのトリックを行います。

MySQLでの作業が私たちのプロジェクトで重要性を増しているので、可能であれば、実際のパフォーマンスの差の値を誰かがガイドしてくれますか？

OPTIMIZE TABLEはデフラグを実行しないことに注意してください。内部的に、OPTIMIZE TABLEはいくつかの操作（一時ファイルへのデータのコピー、インデックスの再作成、インデックス統計の再計算）を実行します。実際、私が持っている例は、示されているように手動で実行できます。

例：を最適化する場合はmydb.mytable、次のコマンドを入力します。

OPTIMIZE TABLE mydb.mytable;

mysqlは内部で次のことを実行することに注意してください。

CREATE TABLE mydb.mytable2 LIKE mydb.mytable;
ALTER TABLE mydb.mytable2 DISABLE KEYS;
INSERT INTO mydb.mytable2 SELECT * FROM mydb.mytable;
ALTER TABLE mydb.mytable2 ENABLE KEYS;
DROP TABLE mydb.mytable;
ALTER TABLE mydb.mytable2 RENAME mydb.mytable;
ANALYZE TABLE mydb.mytable;

これは、大量のUPDATEおよびDELETEが発生するテーブルに非常に役立ちます。

これを実行すると、2つのことを達成できます。

1. mysqlが適切なサイズのフラグメントにデータをロードしようとしてテーブル内のフラグメントを調べないようにします。これらのフラグメントを削除すると、この操作が減ります。

2. インデックス統計を再計算すると、MySQLクエリオプティマイザーがより優れたEXPLAINプランを構築するのに役立ちます。そうしないと、MySQL Query OptimizerがEXPLAINプランで誤った推測をすることを決定したため、クエリの実行時間が低下する可能性があります。これは、大量のUPDATEとDELETEがあったテーブルの明確な症状です。

警告

キャッシュに関しては、全表スキャンを行うため、キャッシュはすぐに飛び込みます。MyISAMの場合、インデックスページはMyISAMキーキャッシュに出入りします。InnoDBの場合、データページとインデックスページはInnoDBバッファープールに出入りします。