mysql事务和锁

标签：dash   示例   问题：   lock   select   查询   选择   clu   commit   

一，锁

锁是并发控制中最核心的概念之一，在MySQL中的锁分两大类，一种是读锁，一种是写锁，读锁也可以称为共享锁（shared lock），写锁也通常称为排它锁（exclusive lock）。

　　这里先不讨论锁的具体实现，描述一下锁的概念：读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取一个资源，且互不干扰。写锁则是排他的，就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。另外在一般情况下，写锁比读锁优先级高。

　　MySQL中的锁有两种粒度，一种是表锁，在表级别加锁，是MySQL中最基本的锁策略，并且开销最小，这种锁的并发性能较低；另一种为行锁，在行级加锁，并发性较高。表锁与行锁没有绝对的性能强弱之分，在应用中可以根据实际场景选择，在锁粒度与数据安全之间寻求一种平衡机制。

　　锁的具体实现协议大体分为两种：显式锁和隐式锁。显式锁是指根据用户需要手动去请求的锁。隐式锁则是指存储引擎自行根据需要施加的锁。显式锁的用法示例：

　　例1：开启两个ssh连接同一主机，进入MySQL，在连接A上对表tbl2做读锁操作：

1 mysql> USE mysql;
2 mysql> LOCK TABLE tbl2 READ;

　　在连接B上读取数据是可以的，但是写入数据不行：

1 mysql> USE mysql;
2 mysql> SELECT * FROM tbl2;
3 mysql> INSERT INTO tbl2 VALUES (1,‘tom‘); #会一直卡在这一步，不向后执行。

　　当在连接1上将tbl2解锁后，就能写入数据了：

二，事务

在php与数据库的交互中,如果并发量大,并且都去进行数据库的修改的话,就有一个问题需要注意.数据的锁问题.就会牵扯数据库的事务跟隔离机制

数据库事务依照不同的事务隔离级别来保证事务的ACID特性，也就是说事务不是一开启就能解决所有并发问题。通常情况下，这里的并发操作可能带来四种问题：

• 更新丢失：一个事务的更新覆盖了另一个事务的更新，这里出现的就是丢失更新的问题。
• 脏读：一个事务读取了另一个事务未提交的数据。
• 不可重复读：一个事务两次读取同一个数据，两次读取的数据不一致。
• 幻象读：一个事务两次读取一个范围的记录，两次读取的记录数不一致。

三，事务隔离级别

　　事务的隔离级别有四种：

1.READ UNCOMMITTED（未提交读）

　　在READ UNCOMMITTED级别，事务中的修改即使没有提交，对其它事务也都是可见的。即事务可读取未提交的数据，这称为脏读（Dirty Read）。这会导致很多问题，在实际应用中一般很少用到。

2.READ COMMITED（提交读）

　　READ COMMITTED表示只能读取事务修改提交后的数据。此级别有时候也叫做不可重复读（nonrepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。

3.REPEATABLE READ（可重复读）

　　此级别解决了脏读的问题，保证了在同一个事务中多次同样记录的结果是一致的。但会带来新的问题——幻读（Phantom Read）。MySQL默认使用此级别。

4.SERIALIZABLE（可串行化）

　　SERIALIZABLE是最高的隔离级别。它会强制事务串行执行，避免了幻读、脏读的问题，但是牺牲了并发性。

　　示例：

mysql> SELECT @@session.tx_isolation; #查看当前事务隔离级别
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+
1 row in set (0.00 sec)

 mysql> SET @@session.tx_isolation=‘级别‘; 可设置隔离级别

mysql事务和锁

标签：dash   示例   问题：   lock   select   查询   选择   clu   commit   

原文地址：https://www.cnblogs.com/tkzc2013/p/10997057.html