回答:
インデックスの作成は基本的にソート操作であるため、せいぜいn log n平均で順序の成長の複雑さがあります（場合によっては、それがより良くなり、それほど悪くなることはないでしょう）。
関連するすべてのデータページがRAMに収まり、既にRAMに収まり、インデックスも収まる場合、DBMSは作成が完了する前にインデックスページを強制的に書き込みません（したがって、インデックスブロックはディスク上で複数回更新されません）操作）、結果のインデックスをディスクに書き込む速度は、ソートの実行にかかる時間よりも重要です-したがって、行数とインデックスの作成にかかる時間の線形関係に近づくことがあります-しかし、最悪のケースを想定した場合、不愉快な驚きを感じる可能性は低くなります！
操作中に本番データベースへのアクセスを停止しない場合を除き、インデックス作成はIO帯域幅や他のアクティビティとのロックを競合するため、タイミング推定テストを行う場合はこれを考慮する必要があります。同じように構成されている場合でも、別のシステムで。
また、テーブルのスピンドルからインデックスのスピンドルを分割できる場合は、一度に2つのディスクから作業できることも注目に値します（まだ中央のディスクコントローラーの速度に制限されますRAIDなどですが、それでも1つのディスクより高速です。
インデックスの作成は、完全な同時読み取り/書き込み操作ではないことを理解していますが、かなり高速化されます。
警告：私は自分でMSSQLを使用しているので、MySQLについてはわかりませんが、スピンドルを分割するという概念はSQLServerとOracleに固有のものではないことを想像する必要があります）。そのコンセプトを設定する方法を知りません。ただし、SQLServerの用語では、別のファイルグループに加えPRIMARYてインデックスを他のファイルグループに配置し、他のファイルグループを関係のないスピンドルセットに割り当てることを意味しますPRIMARY（許可されたスピンドル配置とファイルグループは別の話です）
場合によります。
変数＃1：MySQLがインデックスをオンザフライで作成することを選択した場合、またはすべてのデータが入るまで待機した場合、ソートなどを行ってインデックスを作成します。注：一意性を検証できるように、一意のインデックス（と思う）をその場で作成する必要があります。InnoDBのPRIMARY KEYはデータと共に保存されます（または、その逆の場合もあります）ので、ランダムに構築する必要があります。
変数＃2：インデックスは、データ（AUTO_INCREMENTやタイムスタンプなど）とランダム（GUID、MD5）、またはその中間（部品番号、名前、friend_id）を追跡します。
変数＃3（インデックスがオンザフライで構築される場合）：インデックスがキャッシュ（key_bufferまたはinnodb_buffer_pool）に収まるか、ディスクに流出する可能性があります。
データを追跡するインデックスは、1番目の答えに関係なく、効率的で実質的に線形です。
ランダムIDは苦痛です。インデックスがキャッシュに収まらない場合、他の変数に関係なく、インデックスを作成する時間は線形よりもはるかに長くなります。（この場合、Rolandoには同意しません。）PKのGUIDを持つ巨大なInnoDBテーブルは、挿入が非常に遅くなります。通常のディスクでは100行/秒を計画してください。SSDがある場合は、おそらく1000です。LOAD DATAとバッチINSERTを使用しても、ランダムストレージの速度が低下することはありません。
3.53から5.6-ほとんど変更されていません。
複数のスピンドル？RAIDストライピングは、ほとんどすべての状況で、これをこことそこに手動で割り当てるよりも優れています。手動で分割すると、状況が不均衡になります-データスキャンでテーブルスキャンが停止します。インデックスのみの操作がインデックスディスクに残っています。単一のクエリが最初にインデックスディスクにヒットし、次にデータディスクにヒットします（オーバーラップなし）。等