Amazon RDS Customer Data Import Guide for MySQL (2009 年に作成) には、MySQL の読み込み時間を短縮するための次のヒントが記載されています。
ロードする前に、すべてのセカンダリ インデックスを作成します。これは、他のデータベースに精通している人にとっては直感に反するものです。セカンダリ インデックスを追加または変更すると、MySQL はインデックスの変更を含む新しいテーブルを作成し、既存のテーブルから新しいテーブルにデータをコピーし、元のテーブルを削除します。
ただし、2010 年以降のいくつかの記事とスタックオーバーフローの投稿では、読み込み後にインデックスを作成する方がパフォーマンスが高いことを示すパフォーマンス テストが提供されています。これはどこから来て、MySQL の古いバージョンに適用されたのですか? もしそうなら、正確な詳細を提供してください。それとも、特定の場合に適用されますか?
セカンダリ インデックスの処理方法が原因で、古い MySQL バージョン (< 5.5) に適用されるデータをロードする前にセカンダリ インデックスを配置するという AWS の推奨事項:
従来、セカンダリ インデックスの作成と削除には、InnoDB テーブル内のすべてのデータをコピーすることによる大きなオーバーヘッドが伴いました。InnoDB プラグインの高速インデックス作成機能により、InnoDB セカンダリ インデックスの CREATE INDEX ステートメントと DROP INDEX ステートメントの両方が大幅に高速化されます。
MySQL は、5.5 のドキュメントで次の推奨事項を提供しています。
インデックスのメンテナンスは多くのデータ転送操作にパフォーマンスのオーバーヘッドを追加する可能性があるため、セカンダリ インデックスを配置せずに ALTER TABLE ... ENGINE=INNODB または INSERT INTO ... SELECT * FROM ... などの操作を実行し、後でインデックスを作成することを検討してください。 .
AWS で MySQL 5.5 以降を使用している場合は、セカンダリ インデックスの作成を大幅に高速化する高速インデックス作成機能を利用できます。
高速インデックス作成は、InnoDB プラグインで最初に導入された機能であり、現在は 5.5 以降の MySQL サーバーの一部であり、関連付けられたテーブルを完全に書き換える必要を回避することで、InnoDB セカンダリ インデックスの作成を高速化します。高速化は、セカンダリ インデックスの削除にも適用されます。