摘要：
一直以為"insert into tb select * from tbx" 這樣的導入操作是會把tbx表給鎖住的，在鎖期間是不允許任何操作（保證一致性）。看完這篇寫的之后，發現tbx表是會被鎖住，但這個鎖有2種情況，現在逐一進行分析：
分析
環境：
root@127.0.0.1 : test 02:10:40>select @@global.tx_isolation,@@session.tx_isolation; +-----------------------+------------------------+ | @@global.tx_isolation | @@session.tx_isolation | +-----------------------+------------------------+ | REPEATABLE-READ | REPEATABLE-READ | +-----------------------+------------------------+ 1 row in set (0.00 sec) root@127.0.0.1 : test 02:10:50>select @@version; +------------+ | @@version | +------------+ | 5.6.10-log | +------------+ 1 row in set (0.00 sec)
1：按照主鍵排序插入的情況
直接插入，不加排序字段（默認）：
session1：執行操作,表只有5W條記錄 root@127.0.0.1 : test 02:10:51>insert into uu select * from user; session2：查看操作鎖的情況（鎖的行數） root@127.0.0.1 : (none) 02:13:30>pager grep "lock(s)" PAGER set to 'grep "lock(s)"'root@127.0.0.1 : (none) 02:18:08>show engine innodb status; #被鎖的行數逐步增加 274 lock struct(s), heap size 31160, 17746 row lock(s), undo log entries 17474
root@127.0.0.1 : (none) 02:18:16>show engine innodb status; 500 lock struct(s), heap size 63928, 32572 row lock(s), undo log entries 32074
root@127.0.0.1 : (none) 02:18:17>show engine innodb status; 676 lock struct(s), heap size 80312, 44308 row lock(s), undo log entries 43635
用主鍵升序插入：
情況和1一樣。即默認的"select * from tb" 和 "select * from tb order id(PK) ASC " 是一樣的情況。
用主鍵倒序插入：
情況和1一樣。即默認的"select * from tb" 和 "select * from tb order id(PK) DESC" 是一樣的情況，這里說的一樣是鎖方式一樣（都是逐步，只是順序不一樣）。
從上面可知：通過主鍵排序或則不加排序字段的導入操作"insert into tb select * from tbx"，是會鎖tbx表，但他的鎖是逐步地鎖定已經掃描過的記錄。
2：按照非主鍵排序插入的情況
session1：執行操作 root@127.0.0.1 : test 02:33:00>insert into uu select * from user order by createTime ; session2：查看操作鎖的情況（行數） root@127.0.0.1 : (none) 02:27:29>pager grep "lock(s)" root@127.0.0.1 : (none) 02:27:54>show engine innodb status; #被鎖的行數一樣，不變（整張表） 773 lock struct(s), heap size 80312, 50771 row lock(s), undo log entries 1843
root@127.0.0.1 : (none) 02:33:19>show engine innodb status; 773 lock struct(s), heap size 80312, 50771 row lock(s), undo log entries 17680
root@127.0.0.1 : (none) 02:33:20>show engine innodb status; 773 lock struct(s), heap size 80312, 50771 row lock(s), undo log entries 22260
root@127.0.0.1 : (none) 02:33:21>show engine innodb status; 773 lock struct(s), heap size 80312, 50771 row lock(s), undo log entries 28960
從上面可知：通過非主鍵排序的導入操作"insert into tb select * from tbx"，是會鎖tbx表，但他的鎖是一開始就會鎖定整張表。
總之，"insert into tb select * from tbx" 的導入操作是會鎖定原表，但是鎖是有2種情況：“逐步鎖”，“全鎖”。
驗證：
針對1的情況：逐步鎖定掃描過的記錄，那操作未掃描的數據會怎么樣？
session1：執行操作 root@127.0.0.1 : test 02:55:27>insert into uu select * from user; Query OK, 49998 rows affected (9.06 sec) session2：測試操作鎖的情況 root@127.0.0.1 : test 02:54:49>delete from user where id = 33333;update user set username='TEST' where id = 44444;insert into user(id,username,company) values(1000,'ASD','ABCASDA'); Query OK, 0 rows affected (0.00 sec) #可以刪除未掃描（鎖）的數據(id=33333) Query OK, 0 rows affected (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 0 #可以更新為掃描（鎖）的數據(id=44444) Query OK, 1 row affected (8.09 sec)#插入（更新，刪除）操作被鎖了，因為該記錄已經被掃描到(id=1000) session3：查看操作的鎖情況： root@127.0.0.1 : (none) 02:55:33>show engine innodb status; LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 272 lock struct(s), heap size 31160, 17574 row lock(s), undo log entries 17305 1 row in set (0.09 sec) root@127.0.0.1 : (none) 02:55:35>show engine innodb status; LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 448 lock struct(s), heap size 47544, 29109 row lock(s), undo log entries 28664 1 row in set (0.01 sec) root@127.0.0.1 : (none) 02:55:37>show engine innodb status; LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 612 lock struct(s), heap size 63928, 40034 row lock(s), undo log entries 39425 1 row in set (0.00 sec) root@127.0.0.1 : (none) 02:55:39>show engine innodb status; 1 row in set (0.01 sec)
從上面看出，剛好說明了1的情況：逐步的鎖定已經掃描過的記錄。
默認、主鍵升序的select ：從第一行開始掃描到最后，即第一行開始鎖直到最后。
主鍵倒序select ：從最后一行開始掃描到最前，即最后一行開始鎖直到第一行。
針對2的情況：鎖定整張表，那就是表鎖；不能進行任何操作，直到鎖釋放了？
session1：執行操作 root@127.0.0.1 : test 03:23:06>insert into uu select * from user order by company; Query OK, 49994 rows affected (13.70 sec) session2：測試操作鎖的情況 root@127.0.0.1 : test 03:22:44>delete from user where id = 33337;update user set username='TESAAST' where id = 44443;insert into user(id,username,company) values(1000,'ASD','ABCASDA'); Query OK, 1 row affected (9.58 sec) #直接被鎖住了，等待session1釋放了。 Query OK, 0 rows affected (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 0 #同上 Query OK, 1 row affected (0.00 sec) #同上 session3：查看操作的鎖情況： root@127.0.0.1 : (none) 03:22:45>pager grep "lock(s)" PAGER set to 'grep "lock(s)"' root@127.0.0.1 : (none) 03:23:20>show engine innodb status; 773 lock struct(s), heap size 80312, 50765 row lock(s), undo log entries 4433 1 row in set (0.02 sec) root@127.0.0.1 : (none) 03:23:28>show engine innodb status; LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 773 lock struct(s), heap size 80312, 50765 row lock(s), undo log entries 25383 1 row in set (0.06 sec) root@127.0.0.1 : (none) 03:23:32>show engine innodb status; LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 773 lock struct(s), heap size 80312, 50765 row lock(s), undo log entries 42464 1 row in set (0.01 sec)
從上面看出，剛好說明了2的情況：一開始就會鎖定整張表的記錄，不能進行任何操作，直到鎖釋放了。
總結：
類似"insert into tb select * from tbx" 的操作，最好確保tbx表不被做dml操作，不然很可能出現鎖等待的情況。另：通過設置隔離級別：read committed & ROW(binlog_format)可以讓dml和該語句並發操作。
View Code
session1：執行操作 root@127.0.0.1 : test 04:05:08>insert into uu select * from user order by company; Query OK, 49990 rows affected (14.09 sec) session2：測試操作鎖的情況 root@127.0.0.1 : test 04:04:57>delete from user where id = 33318;update user set username='TESAAeST' where id = 44423;insert into user(id,username,company) values(1000,'ASD','ABCASDA'); Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 0 Query OK, 1 row affected (0.00 sec) session3：查看操作的鎖情況： root@127.0.0.1 : (none) 03:22:45>pager grep "lock(s)" PAGER set to 'grep "lock(s)"' root@127.0.0.1 : test 04:05:23>show engine innodb status; 1 lock struct(s), heap size 376, 0 row lock(s), undo log entries 6256 1 row in set (0.05 sec) root@127.0.0.1 : test 04:05:28>show engine innodb status; 1 lock struct(s), heap size 376, 0 row lock(s), undo log entries 32958 1 row in set (0.01 sec) root@127.0.0.1 : test 04:05:35>show engine innodb status; 1 lock struct(s), heap size 376, 0 row lock(s), undo log entries 33784 1 row in set (0.00 sec) root@127.0.0.1 : test 04:05:36>show engine innodb status; 1 lock struct(s), heap size 376, 0 row lock(s), undo log entries 34789 1 row in set (0.00 sec)
其他：
詳細的說明和測試請見：http://www.zhaokunyao.com/archives/4326