At Thu, 26 Aug 1999 11:26:07 +0900,
Yuzuru Goto <kn6y-gtu@xxxxxxxxxx> wrote:

> 一つ目のindexや二つ目のindex作成時には時間がかからず
> indexをつける項目が増えるにつれこれを作成する為の時間が
> 急激に増えていくというものでした。
> 
> ということで、今回の宮原さんの件とは少しかけはなれた話でした。

わたしは、同じだと思ってます

  クライアント　　　　　　　　サーバー
  mysql command で
  alter table      - 要求 -> おおもと(親)の mysqld thread が受け
                                \違うスレッド(子)に処理させる
                                  |
                                  V
                               違う(子)スレッドが alter table 実行
                                  今のテーブル(.ISD, .ISM) を
                                  一行一行、チェック、変更して
                                  A-1.* にコピー

                                  A-1.* が完成したら、A-1.* を
                                  テーブル名.* にリネーム

                                  データが何百メガとかあると、
                                  disk をがりがりやってしまう

                               処理終了後、おおもとの親 mysqld に返る
                                  |
                                  V
   mysql コマンドが  <- 返 -  親 mysqld が返答
  結果受け取り

の流れです。 (あれ、子供が直接返答するのだったけ？)

インデックスは、"テーブル名.ISM" というファイルにかかれます
全部のデータは "テーブル名.ISD" というファイルです。

ですので、はるインデックスが多くなれば、.ISM も多くなりますし、
書き込みもチェックも多くなります。
結果、disk アクセスが多くなって、遅くなります


あと、上の流れの通り、クライアントである mysql コマンドは
単に要求を発行して、受け取りを待っているだけなので、
クライアントの "mysql コマンド" を落としても、
命令を実行しようとしているサーバーのスレッドにはあまり影響せず、
"なにも返ってこない" とか "暴走した" とか、
操作した人間は思ってしまいます。

さらに、親の mysqld スレッドを kill しても
( mysql.server stop は 親の mysqld スレッドを kill しているだけ )
子供のスレッドが命令を完遂しようとしていますので、
kill できなかったりとか、
あるいは、親を kill -9 しても、子は別のプロセスで仕事し続けているだとか、
と、いうことになります。
# やはり mysqladmin コマンドで落とすのが正攻法かと


こういう処理ですので、
mysqldump (or mysql> SELECT ... INTO OUTFILE) で取ったものを
mysqlimport (or mysql> LOAD DATA INFILE .... ) で戻すよりも
遅いです。

# MySQL は一般ファイルに書いているという点が弱点であり、
# また気軽に扱えるという利点でもありで...

-- 
 村上 毅  takeshi@xxxxxxxxxx