MySQL学习笔记

MySQL锁机制

锁的分类

从对数据操作的类型来说：
- 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响。
- 写锁（排它锁）：当前写操作没有完成前，他会阻断其他写锁和读锁。
从对数据操作的粒度分类：行锁和表锁

三锁

开销、加锁速度、死锁、粒度、并发性能只能就具体应用的特点来说哪种锁更加合适
三锁：表锁（偏读），行锁（偏写），页锁。

表锁

特点：偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
下面演示加读锁

mysql> create table mylock(
    -> id int not null primary key auto_increment,
    -> name varchar(20)
    -> )engine myisam;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into mylock(name) values('a');
Query OK, 1 row affected (0.01 sec)

mysql> insert into mylock(name) values('b');
Query OK, 1 row affected (0.00 sec)

mysql> insert into mylock(name) values('c');
Query OK, 1 row affected (0.00 sec)

mysql> insert into mylock(name) values('d');
Query OK, 1 row affected (0.00 sec)

mysql> insert into mylock(name) values('e');
Query OK, 1 row affected (0.00 sec)

mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)

#手动增加表锁
# lock table 表名 read(write),表名２ read(write), ...;
mysql> lock table mylock read,book write;
Query OK, 0 rows affected (0.00 sec) 

#查看表上加过的锁
#此处省略了部分其他表
mysql> show open tables;
+--------------------+------------------------------------------------------+--------+-------------+
| Database           | Table                                                | In_use | Name_locked |
| db26               | mylock                                               |      1 |           0 |
| db26               | book                                                 |      1 |           0 |

#解锁
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)

mysql> show open tables;
+--------------------+------------------------------------------------------+--------+-------------+
| Database           | Table                                                | In_use | Name_locked |
| db26               | mylock                                               |      0 |           0 |
| db26               | book                                                 |      0 |           0 | 



#下面进行演示，
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)

mysql> lock table mylock read;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)

#下面是使用了另一个session2进行操作
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)
/*读锁是共享锁*/

#session1操作
mysql> update mylock set name='a2' where id=1;
ERROR 1099 (HY000): Table 'mylock' was locked with a READ lock and can't be updated

mysql> select * from book;
ERROR 1100 (HY000): Table 'book' was not locked with LOCK TABLES

可以发现，session1加了读锁之后，只能对该表进行读的操作，对该表的任何其他操作都是非法，同时，也不能对其他表进行任何操作了。session2对该表的读以及对其他表的任何操作不受到影响，然而如果对该表进行修改，会发生阻塞（也就是光标会不断闪烁），何时该表解锁，何时阻塞可以通过。
下面演示加写锁

mysql> lock table mylock write;
Query OK, 0 rows affected (0.00 sec)
 
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a2   |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)

mysql> update mylock set name='a4' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from book;
ERROR 1100 (HY000): Table 'book' was not locked with LOCK TABLES
/*发现不能查看其他表*/

#使用session2操作
mysql> select * from mylock;
/*发现阻塞*/

发现加了写锁之后，只有本session可以进行读写操作，但是不能操作其他表，其他session无法对该表进行任何操作。
MyISAM在执行查询语句（select）前，会自动给涉及到的所有表加读锁，在执行增删改操作前，会自动给涉及到的表加写锁。MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）表独占写锁（Table Write Lock）
结合上表，对MyISAM表进行操作，会有以下情况：
- 对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其他进程的写操作。
- 对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放之后，才会执行其他进程的读写操作。
简而言之：读锁会阻塞写，但不会阻塞读。而写锁会把读写都阻塞。

表锁分析

查看哪些表被加锁了：

show open tables;

如何分析表锁定：可以通过检查table_locks_immediate和table_locks_waited状态变量来分析系统上的表锁定：

mysql> show status like 'table%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Table_locks_immediate      | 113   |
| Table_locks_waited         | 0     |
| Table_open_cache_hits      | 3     |
| Table_open_cache_misses    | 10    |
| Table_open_cache_overflows | 0     |
+----------------------------+-------+
5 rows in set (0.00 sec)

第一个变量表示产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1；
第二个变量表示出现标记锁定争用而发生等待的次数（不能立即获取表的次数，每等待一次锁值加1），此值高就说明存在较严重的表级锁争用情况。
此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永久阻塞。

行锁

特点：偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。InnoDB与MyISAM的最大不同有两点：一是支持事务（transaction）；二是采用了行级锁。
事务是由一组SQL语句组成的逻辑处理单元，事务具有以下四个属性，通常简称为事务的ACID属性：
- 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全部执行，要么全部不执行；
- 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
- 隔离性（Isolation）：数据库系统提供了一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可间的，反之亦然。
- 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够维持。
并发事务处理带来的问题：
- 更新丢失（Lost Update）
- 脏读（Dirty Reads）
- 不可重复读（Non-Repeatable Reads）
- 幻读（Phantom Reads）
事务隔离级别：脏读、不可重复读和幻读，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

读数据一致性及允许的并发副作用隔离级别	读数据一致性	脏读	不可重复读	幻读
未提交读	最低级别，只能保证不读取物理上损坏的数据	是	是	是
已提交读	语句级	否	是	是
可重复读	事务级	否	否	是
可序列化	最高级别，事务级	否	否	否

数据库的事务隔离越严格，并发副作用越小，但是付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”矛盾。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问能力。
查看当前数据库事务隔离级别：

show variables like 'tx_isolation';

mysql> create table test_innodb_lock(a int(11),b varchar(16))engine=innodb;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test_innodb_lock values(1,'b2');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(3,'3');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(4,'4000');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(5,'5000');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(6,'6000');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(7,'7000');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test_innodb_lock values(8,'8000');
Query OK, 1 row affected (0.11 sec)

mysql> insert into test_innodb_lock values(9,'9000');
Query OK, 1 row affected (0.27 sec)

mysql> insert into test_innodb_lock values(1,'b1');
Query OK, 1 row affected (0.00 sec)

mysql> create index test_innodb_a_ind on test_innodb_lock(a);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> create index test_innodb_lock_b_ind on test_innodb_lock(b);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

先对两个session进行：set autocommit=0;这样相当于造成了阻塞，不会自动提交。
然后对session1进行操作：

mysql> update test_innodb_lock set b='4001' where a=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4001 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9000 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)

然而，此时再对session2进行操作，会发现，表中数据并没有发生变化。

mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4000 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9000 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)

这时候，使用session1进行commit操作，session2仍不能查询出正确的结果。正确做法是session2也进行一次commit，这样之后，再次进行查询就可以得到正确结果了。
如果进行以下操作：

#session1
mysql> update test_innodb_lock set b='4002' where a=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

#session2
mysql> update test_innodb_lock set b='4003' where a=4;

/*发生了阻塞，说明行锁有了作用*/


#session1
mysql> update test_innodb_lock set b='4005' where a=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

#session2
mysql> update test_innodb_lock set b='9001' where a=9;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
/*这种情况，发现两边都会正常执行，行锁不影响其他行*/

要注意的是，无索引或者索引失效时，行锁就会变成表锁，极大降低了性能。
如果session1执行了update test_innodb_lock set b ='0629' where a>1 and a<6;，session2执行insert into test_innodb_lock values(2,'2000');注意，a=2这一行是不存在的，且此时session1没有commit，发现session2发生了阻塞。然后session1进行commit，此时a=2这一行正常加入了表中。
当使用范围条件而不是相等条件检索数据，并请求共享或排它锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做间隙GAP。InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁。
间隙锁的危害：因为Query执行过程中通过范围查找的话，会锁定整个范围内所有索引键值，即使这个键值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。
如何锁定某一行：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

#进行上锁
mysql> select * from test_innodb_lock where a=8 for update;
+------+------+
| a    | b    |
+------+------+
|    8 | 8000 |
+------+------+
1 row in set (0.00 sec)

#解锁，期间别的进程都会被阻塞 
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

InnoDB存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力要远远由于MyISAM的表级锁定。当系统并发量较高的时候，InnoDB的整体性能和MyISAM相比就会有比较明显的优势了。
但是，InnoDB的行级锁定同样也有其脆弱的一面，当我们使用不当时，可能会让InnoDB的整体性能甚至差于MyISAM。
如何分析行锁定：show status like 'innodb_row_lock%';
- ...current_waits:当前正在等待锁定的数量。
- ...time:从系统启动到现在锁定总时间长度。
- ...time_avg:每次等待所花平均时间
- ...time_max:最长一次时间
- ...waits:从系统启动到现在总共等待次数
对于这五个状态变量，比较重要的是等待平均时长，等待总次数，等待总时长。

优化建议

尽可能让数据检索都通过索引来完成，避免无索引行锁升级成表锁
合理设计索引，尽量缩小锁的范围
尽可能较少检索条件，避免间隙锁
尽量控制事务大小，减少锁定资源量和时间长度。
尽可能低级别事务隔离。

页锁

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。只需要了解即可。