mysql中的锁都有哪些(mysql锁类型)

MySQL中有哪些锁？

数据库中锁的设计初衷处理并发问题，作为多用户共享资源，当出现并发访问的时候，数据库需要合理控制资源访问规则。锁就是实现这些访问规则中的重要数据。

锁的分类

根据加锁范围，MySQL里面的锁可以分成全局锁、表级锁、行锁三类。

全局锁

全局锁，就是对整个数据库实例加锁，MySQL提供了一个加全局读锁的方法，命令是:

Flushtableswithreadlock(FTWRL)

当需要整个库只读状态的时候，可以使用这个命令，之后其他线程的：数据更新语句（增删改），数据定义语句（建表，修改表结构）和更新事务的提交语句将会被阻塞。

全局锁的使用场景

全局锁的定型使用场景，做全库逻辑备份。也就是把整个库每个表都Select出来，然后存成文本。

如何整个库都只读，会有什么问题？如果你在主库上备份，那么在备份期间都不能执行更想，业务就基本上停摆。如果在从库上备份，那么备份期间从库不能执行主库同步过来的binlog,会导致从延迟。既然要全库只读，为什么不使用setglobalreadonly=true的方式呢

readonly方式也可以让全库进入只读状态,但我还是会建议你用FTWRL方式，主要有两个原因：

一是，在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大，我不建议你使用。二是，在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高表级别锁

MySQL里面表级别的锁有两种：一种是表锁，一种是元数据锁（metadatalok,MDL）。表锁的语法是：

locktablesread/write

与FTWRL类似,可以使用unlocktables主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，locktables语法除了会限制别的线程的读写外，也限定了本线程接下来的 *** 作对象。

MDL表级锁

MDL不需要显示使用，在访问一个表的时候自动加上，MDL保证读写的正确性，也就是说在查询数据时，不允许有其他线程对这个表结构做变更。

什么 *** 作会加MDL锁？

在MySQL55版本中引入了MDL，当对一个表做增删改查 *** 作的时候，加MDL读锁；当要对表做结构变更 *** 作的时候，加MDL写锁。

读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。读写之间、写锁之间是互斥的，用来保证变更表结构 *** 作的安全性，如果有两个线程要同时给一个表加字段，其中一个要等另外一个执行完才能执行。更改表结构要注意哪些？

给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。在对大表 *** 作的时候，你肯定会特别小心，以免对线上服务造成影响。而实际上，即使是小表， *** 作不慎也会出问题，导致整个库的线程爆满。

举个例子

我们来看一下下面的 *** 作序列，假设表t是一个小表。

image

sessionA先启动，这时候会对表t加一个MDL读锁。由于sessionB需要的也是MDL读锁，因此可以正常执行。sessionC会被blocked，是因为sessionA的MDL读锁还没有释放，而sessionC需要MDL写锁，因此只能被阻塞，读写锁互斥。如果只有sessionC自己被阻塞还没什么关系，但是之后所有要在表t上新申请MDL读锁的请求也会被sessionC阻塞。前面我们说了，所有对表的增删改查 *** 作都需要先申请MDL读锁，就都被锁住，等于这个表现在完全不可读写了。

如果某个表上的查询语句频繁，而且客户端有重试机制，也就是说超时后会再起一个新session再请求的话，这个库的线程很快就会爆满。事务中的MDL锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放。

怎么解决这个更改表结构问题

比较理想的机制是，在altertable语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。

ALTERTABLEtbl_nameNOWAITaddcolumnALTERTABLEtbl_nameWAITNaddcolumn

半专业回答：

1, 这是个疑问句吗

2，如果只是 读 *** 作是不会加锁的

3，事务2 什么 *** 作都不行

4，事务2 可以加共享锁，不能加排他锁

问题补充回答

读 *** 作就是select ，任何时刻都可以，因为是非阻塞读，由UNDO机制实现

共享锁是保证表结构不能被更改，但是可以更改没有加排他锁的数据

共享锁是表级的，排他锁是行级的

where SalesOrderID='43662'SELECT resource_type, request_mode, resource_description,request_session_id, DB_NAME(resource_database_id)as resource_databaseFROM sysdm_tran_locksWHERE resource_type <>'DATABASE'--ROLLBACK TRAN 在事务回滚之前, 查看锁的类型: 其他session对Table只读, 不能更新, 在开一个新的session测试:select from SalesSalesOrderHeader where SalesOrderID='43662'goupdate SalesSalesOrderHeader set OrderDate=GETDATE() where SalesOrderID='43662' select可以正常执行, update语句一直处于等待状态, 等待上面的session释放锁 2 Update locks (U): 更新锁是共享锁和独占锁的组合用UPDLOCK保持更新锁USE AdventureWorks2008BEGIN TRANselect from SalesSalesOrderHeader WITH(UPDLOCK)where SalesOrderID='43662'SELECT resource_type, request_mode, resource_description,request_session_id,DB_NAME(resource_database_id)as resource_databaseFROM sysdm_tran_locksWHERE resource_type <>'DATABASE'ROLLBACK TRAN 查看到锁的信息: 3Exclusive locks (X): 独占锁是为了锁定数据被一个session修改的数据, 而不能够被另外的session修改 只能指定NOLOCK来读取USE AdventureWorks2008BEGIN TRANupdate SalesSalesOrderHeader set ShipDate=GETDATE() where SalesOrderID='43662'WHERE resource_type <>'DATABASE'ROLLBACK TRAN 查看锁: 4Intent locks (I): 意向锁用于建立锁的层次结构 意向锁包含三种类型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。 数据库引擎使用意向锁来保护共享锁(S 锁)或排他锁(X 锁)放置在锁层次结构的底层资源上。 意向锁之所以命名为意向锁，是因为在较低级别锁前可获取它们，因此会通知意向将锁放置在较低级别上。 意向锁有两种用途： 防止其他事务以会使较低级别的锁无效的方式修改较高级别资源。 提高数据库引擎在较高的粒度级别检测锁冲突的效率。

修改方法

有两种方法可以对配置了 systemd 的程序进行资源隔离：1 命令行修改：通过执行 systemctl set-property 命令实现，形式为 systemctl set-property name parameter=value；修改默认即时生效。2 手工修改文件：直接编辑程序的 systemd unit file 文件，完成之后需手工执行 systemctl daemon-reload 更新配置，并重启服务 systemctl restart nameservice。

systemd unit file 里支持的资源隔离配置项，如常见的：

CPUQuota=value

该参数表示服务可以获取的最大 CPU 时间，value 为百分数形式，高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpucfs_quota_us 配置项对应。

MemoryLimit=value

该参数表示服务可以使用的最大内存量，value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memorylimit_in_bytes 配置项对应。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。

READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                    

Gap locking 仅用于外键约束检查和重复键检查。

REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。

SERIALIZABLE           序列化在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

MyISAM和InnoDB存储引擎使用的锁：

封锁粒度小：

由于InnoDB存储引擎支持的是行级别的锁，因此意向锁（因为意向锁是表锁）其实不会阻塞除全表扫以外的任何请求。故表级意向锁与行级锁的兼容性如下所示

参考

参考

行锁的三种算法：

这条语句阻止其他事务插入10和20之间的数字，无论这个数字是否存在。 间隙可以跨越0个，单个或多个索引值。

>

全局锁

顾名思义，全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是Flushtableswithreadlock(FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。

表级锁

MySQL里面表级别的锁有两种：一种是表锁，一种是元数据锁（metadatalock，MDL)。

表锁

表锁的语法是locktablesread/write。与FTWRL类似，可以用unlocktables主动释放锁，也可以在客户端断开的时候自动释放。需要注意，locktables语法除了会限制别的线程的读写外，也限定了本线程接下来的 *** 作对象。

元数据锁

MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是，保证读写的正确性。你可以想象一下，如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。

分别是原子性、一致性、隔离性、持久性。

原子性是指事务包含的所有 *** 作要么全部成功，要么全部失败回滚，因此事务的 *** 作如果成功就必须要完全应用到数据库，如果 *** 作失败则不能对数据库有任何影响。

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。

隔离性是当多个用户并发访问数据库时，比如同时 *** 作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的 *** 作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的 *** 作。例如我们在使用JDBC *** 作数据库时，在提交事务方法后，提示用户事务 *** 作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。

在数据库 *** 作中，在并发的情况下可能出现如下问题：

正是为了解决以上情况，数据库提供了几种隔离级别。

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。

虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。

悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。

商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

如果不采用锁，那么 *** 作方法如下：

但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步 *** 作中，查询出来的商品status为1。但是当我们执行第三步Update *** 作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。

在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新 *** 作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0;

设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：

上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。

上面的第一步我们执行了一次查询 *** 作： select status from t_items where id=1 for update; 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT FOR UPDATE 或 LOCK IN SHARE MODE *** 作同一个数据时才会等待其它事务结束后才执行，一般 SELECT 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update; 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update; 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1; 则能正常查询出数据，不会受第一个事务的影响。

使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：

1、 select from t_items where id=1 for update;

这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。

2、 select from t_items where id=3 for update;

这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。

3、 select from t_items where name='手机' for update;

这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。

4、 select from t_items where id>0 for update; 或者 select from t_items where id>1 for update; （注：>在SQL中表示不等于）

上述两条语句的主键都不明确，也会产生table lock。

5、 select from t_items where status=1 for update; （假设为status字段添加了索引）

这条语句明确指定了索引，并且有此数据，则产生row lock。

6、 select from t_items where status=3 for update; （假设为status字段添加了索引）

这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：

以上就是关于mysql中的锁都有哪些(mysql锁类型)全部的内容，包括:mysql中的锁都有哪些(mysql锁类型)、关于Oracle数据库锁的问题,表锁,行锁,共享和排他的问题,跪求大神解答、SQL Server表锁定原理以及如何解除锁定等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！