27岁学前端开发，jquery绑定事件不生效

为了故事的顺利发展，我们先建一个表，并向表中插入一些记录，下边是 SQL 语句：

CREATE TABLE hero (

number INT,

name VARCHAR(100),

country varchar(100),

PRIMARY KEY (number),

KEY idx_name (name)

) Engine=InnoDB CHARSET=utf8;

INSERT INTO hero VALUES

(1,‘l 刘备’,‘蜀’),

(3,‘z 诸葛亮’,‘蜀’),

(8,‘c 曹操’,‘魏’),

(15,‘x 荀彧’,‘魏’),

(20,‘s 孙权’,‘吴’);

现在 hero 表中的记录情况就如下所示：

mysql> SELECT * FROM hero;

±——-±———–±——–+

| number | name | country |

±——-±———–±——–+

| 1 | l 刘备 | 蜀 |

| 3 | z 诸葛亮 | 蜀 |

| 8 | c 曹操 | 魏 |

| 15 | x 荀彧 | 魏 |

| 20 | s 孙权 | 吴 |

±——-±———–±——–+

5 rows in set (0.01 sec)

现象

在小册答疑群里有一位同学提了一个问题：说是在 READ COMMITTED 隔离级别下发生了一件百思不得其解的事儿。好的，首先构造环境，将当前会话默认的隔离级别设置成READ COMMITTED：

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

Query OK, 0 rows affected (0.00 sec)

事务 T1 先执行：

T1 中，隔离级别为 READ COMMITTED

mysql> BEGIN;

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM hero WHERE country =‘魏’FOR UPDATE;

±——-±——–±——–+

| number | name | country |

±——-±——–±——–+

| 8 | c 曹操 | 魏 |

| 15 | x 荀彧 | 魏 |

±——-±——–±——–+

2 rows in set (0.01 sec)

country列并不是索引列，所以本条语句执行时肯定是使用扫描聚簇索引的全表扫描方式来执行，EXPLAIN语句也证明了我们的想法：

mysql> EXPLAIN SELECT * FROM hero WHERE country =‘魏’FOR UPDATE;

±—±————±——±———–±—–±————–±—–±——–±—–±—–±———±————+

| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

±—±————±——±———–±—–±————–±—–±——–±—–±—–±———±————+

| 1 | SIMPLE | hero | NULL | ALL | NULL | NULL | NULL | NULL | 5 | 20.00 | Using where |

±—±————±——±———–±—–±————–±—–±——–±—–±—–±———±————+

1 row in set, 1 warning (0.02 sec)

我们之前学过 MySQL 语句的加锁分析，知道在 READ COMMITTED 隔离级别下，如果采用全表扫描的方式执行查询语句时，InnoDB 存储引擎将依次对每条记录加正经记录锁，在 server 层测试该记录是否符合 WHERE 条件，如果不符合则将加在该记录上的锁释放掉。本例中使用 FOR UPDATE 语句，肯定加的是 X 型正经记录锁。只有两条记录符合 WHERE 条件，所以最终其实只对这两条符合条件的记录加了 X 型正经记录锁（就是number 列值为 8 和15的两条记录）。当然，我们可以使用 SHOW ENGINE INNODB STATUS 命令证明我们的分析：

mysql> SHOW ENGINE INNODB STATUSG

… 省略了很多内容

TRANSACTIONS

Trx id counter 39764

Purge done for trx’s n:o

History list length 36

Total number of lock structs in row lock hash table 1

LIST OF TRANSACTIONS FOR EACH SESSION:

—TRANSACTION 281479653009568, not started

0 lock struct(s), heap size 1160, 0 row lock(s)

—TRANSACTION 281479653012832, not started

0 lock struct(s), heap size 1160, 0 row lock(s)

—TRANSACTION 39763, ACTIVE 468 sec

2 lock struct(s), heap size 1160, 2 row lock(s)

MySQL thread id 19, OS thread handle 123145470611456, query id 586 localhost 127.0.0.1 root

TABLE LOCK table xiaohaizi.hero trx id 39763 lock mode IX

RECORD LOCKS space id 287 page no 3 n bits 72 index PRIMARY of table xiaohaizi.hero trx id 39763 lock_mode X locks rec but not gap

Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0

0: len 4; hex 80000008; asc ;;

1: len 6; hex 000000009b4a; asc J;;

2: len 7; hex 80000001d3012a; asc *;;

3: len 7; hex 63e69bb9e6938d; asc c ;;

4: len 3; hex e9ad8f; asc ;;

Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0

0: len 4; hex 8000000f; asc ;;

1: len 6; hex 000000009b4a; asc J;;

2: len 7; hex 80000001d30137; asc 7;;

3: len 7; hex 78e88d80e5bda7; asc x ;;

4: len 3; hex e9ad8f; asc ;;

… 省略了很多内容

其中 id 为39763的事务就是指 T1，可以看出它为heap no 值为 4 和5的两条记录加了 X 型正经记录锁（lock_mode X locks rec but not gap）。

然后再开启一个隔离级别也为 READ COMMITTED 的事务T2，在其中执行：

最后

除了简历做到位，面试题也必不可少，整理了些题目，前面有 117 道汇总的面试到的题目，后面包括了 HTML、CSS、JS、ES6、vue、微信小程序、项目类问题、笔试编程类题等专题。