这就是为什么另外的事务执行类似”insert into myuser(id,user_name,usersex,user_number) values (11,’用户88’,1,’110110110’);”这样的语句，同样会进入等待状态：因为有GAP锁进行独占控制。
4-3-2-3、表锁加锁过程上文已经提到，索引一旦失效InnoDB也会为整个数据表加锁。那么“为整个数据表加锁”这个动作怎么理解呢？很多技术文章在这里一般都概括为一句话“在XXX数据表上加锁”。要弄清楚表锁的加载位置，我们就需要进行实践验证。首先，为了更好的查看InnoDB引擎的工作状态和加锁状态，我们需要打开InnoDB引擎的监控功能：
# 使用以下语句开启锁监控 set GLOBAL innodb_status_output=ON; set GLOBAL innodb_status_output_locks=ON;接下来我们就可以使用myuser数据表中没有键立索引的“usersex”字段进行加锁验证：
begin; update myuser set user_name = \'用户1414\' where usersex = 1; # 先不忙使用commit，以便观察锁状态 #commit;在执行以上事务之前，myuser数据表中最新的记录情况如下图所示：
可以看到myuser数据表中一共有13条记录，其中满足“usersex = 1”的数据一共有9条记录。那么按照InnoDB引擎行锁机制来说，就应该只有这9条记录被锁定，那么是否如此呢？我们通过执行InnoDB引擎的状态监控功能来进行验证：
show engine innodb status; # 以下是执行结果（省略了一部分不相关信息） ===================================== 2016-10-06 22:22:49 2f74 INNODB MONITOR OUTPUT ===================================== ....... ------------ TRANSACTIONS ------------ Trx id counter 268113 Purge done for trx\'s n:o < 268113 undo n:o < 0 state: running but idle History list length 640 LIST OF TRANSACTIONS FOR EACH SESSION: ...... ---TRANSACTION 268103, ACTIVE 21 sec 2 lock struct(s), heap size 360, 14 row lock(s), undo log entries 9 MySQL thread id 5, OS thread handle 0x1a3c, query id 311 localhost 127.0.0.1 root cleaning up TABLE LOCK table `qiang`.`myuser` trx id 268103 lock mode IX RECORD LOCKS space id 1014 page no 3 n bits 152 index `PRIMARY` of table `qiang`.`myuser` trx id 268103 lock_mode X Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;; Record lock, heap no 79 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 8000000a; asc ;; 1: len 6; hex 000000041723; asc #;; 2: len 7; hex 2c000001e423fd; asc , # ;; 3: len 8; hex e794a8e688b73130; asc 10;; 4: len 4; hex 80000000; asc ;; 5: len 4; hex 80018a92; asc ;; Record lock, heap no 80 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 8000000e; asc ;; 1: len 6; hex 000000041721; asc !;; 2: len 7; hex 2b000001db176a; asc + j;; 3: len 8; hex e794a8e688b73134; asc 14;; 4: len 4; hex 80000000; asc ;; 5: len 4; hex 80022866; asc (f;; Record lock, heap no 81 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 80000012; asc ;; 1: len 6; hex 00000004171f; asc ;; 2: len 7; hex 2a000001da17b2; asc * ;; 3: len 8; hex e794a8e688b73138; asc 18;; 4: len 4; hex 80000000; asc ;; 5: len 4; hex 8002c63a; asc :;; Record lock, heap no 82 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 80000016; asc ;; 1: len 6; hex 00000004171d; asc ;; 2: len 7; hex 290000024d0237; asc ) M 7;; 3: len 8; hex e794a8e688b73232; asc 22;; 4: len 4; hex 80000000; asc ;; 5: len 4; hex 80035c3c; asc \<;; Record lock, heap no 86 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 80000001; asc ;; 1: len 6; hex 000000041747; asc G;; 2: len 7; hex 41000002580110; asc A X ;; 3: len 10; hex e794a8e688b731343134; asc 1414;; 4: len 4; hex 80000001; asc ;; 5: len 4; hex 80002b67; asc +g;; ...... 这里为节约篇幅，省略了6条行锁记录...... Record lock, heap no 93 PHYSICAL RECORD: n_fields 6; compact format; info bits 0 0: len 4; hex 80000008; asc ;; 1: len 6;