mysql alter table的過程
今天遇到一個有趣的問題，即多個update操作與alter操作如何來競爭鎖的問題，猜想mysql內部可能會使用一個佇列來控制，但具體是什麼樣的佇列，還不清楚。
簡單的跟蹤了下，一個alter操作其實可以切分成多個過程：
1. 建立一個臨時表，例如（table_name=0x48fa7720 "#sql-2f8e_3"）
2.為臨時表建立索引
3.index_read
4.index_write 將原表的索引資料寫入新索引
5.將原表資料寫入臨時表
6.將原表進行rename，例如：
ha_innobase::rename_table (this=<value optimized out>, from=0x48fa5d10 "./zhaiwx/test", to=0x48fa5b00 "./zhaiwx/#sql2-2f8e-3
7.將臨時表rename為原表，例如：
ha_innobase::rename_table (this=<value optimized out>, from=0x48fa5d10 "./zhaiwx/#sql-2f8e_3", to=0x48fa5b00 "./zhaiwx/test")
8.刪除原表：
ha_innobase::delete_table (this=<value optimized out>, name=0x48fa5de0 "./zhaiwx/#sql2-2f8e-3") at handler/ha_innodb.cc:6622
--------------------------------------------
以上是跟蹤gdb的副產物，真實性有待證實，跟蹤的方法是在lock_table函式設斷點，每次bt，可以很清晰明瞭的看到alter的過程。。。
在一次alter table操作過程中，多次呼叫了lock_table函式。那麼進入該函式，我們可以發現，其做了以下工作：
1.
/* Look for stronger locks the same trx already has on the table */
if (lock_table_has(trx, table, mode)) {
lock_mutex_exit_kernel();
return(DB_SUCCESS);
}
2.
/* We have to check if the new lock is compatible with any locks
other transactions have in the table lock queue. */
if (lock_table_other_has_incompatible(trx, LOCK_WAIT, table, mode)) {
/* Another trx has a request on the table in an incompatible
mode: this trx may have to wait */
err = lock_table_enqueue_waiting(mode | flags, table, thr);
lock_mutex_exit_kernel();
return(err);
}
lock_table_create(table, mode | flags, trx);
-----------------
跟進到lock_table_other_has_incomatible函式，可以發現，會對一個鎖佇列進行遍歷，判斷其中是否有和當前要求的鎖相沖突的，如果有，那麼就需要
呼叫lock_table_enqueue_waiting函式將當前請求加入到鎖佇列中，並等待（除此外，還會檢查是否可能產生死鎖，具體尚未分析）。
可見，mysql是用鎖佇列（lock queue）來控制可能產生衝突的請求，鎖的型別包括：
/* Basic lock modes */
enum lock_mode {
LOCK_IS = 0, /* intention shared */
LOCK_IX, /* intention exclusive */
LOCK_S, /* shared */
LOCK_X, /* exclusive */
LOCK_AUTO_INC, /* locks the auto-inc counter of a table
in an exclusive mode */
LOCK_NONE, /* this is used elsewhere to note consistent read */
LOCK_NUM = LOCK_NONE/* number of lock modes */
};
---------------------------------
mysql鎖的管理還是相當複雜的，本文只是找到了一個研究鎖管理的入口，至於其內部具體如何管理的，還需要更加深入的研究