mysql数据库、锁、事务等概念

最新推荐文章于 2024-12-10 11:09:17 发布

原创最新推荐文章于 2024-12-10 11:09:17 发布 · 388 阅读

3 ·

CC 4.0 BY-SA版权

java web 专栏收录该内容

9 篇文章

订阅专栏

参考：

事务与锁的区别：

事务与锁是不同的。

事务具有ACID（【原子性】、【一致性】、【隔离性】和【持久性】），

锁是用于解决【隔离性】的一种机制。

事务的隔离级别通过锁的机制来实现。

另外锁有不同的粒度，同时事务也是有不同的隔离级别的（一般有四种：读未提交Read uncommitted，
读已提交Read committed，可重复读Repeatable read，可串行化Serializable）。

在具体的程序设计中，开启事务其实是要数据库支持才行的，如果数据库本身不支持事务，那么仍然无法确保你在程序中使用的事务是有效的。

锁可以分为乐观锁和悲观锁：

悲观锁：认为在修改数据库数据的这段时间里存在着也想修改此数据的事务；

乐观锁：认为在短暂的时间里不会有事务来修改此数据库的数据；

我们一般意义上讲的锁其实是指悲观锁，在数据处理过程中，将数据置于锁定状态（由数据库实现）。

如果开启了事务，在事务没提交之前，别人是无法修改该数据的；

如果rollback，你在本次事务中的修改将撤消（不是别人修改的会没有，因为别人此时无法修改）。当然，前提是你使用的数据库支持事务。

还有一个要注意的是，部分数据库支持自定义SQL锁覆盖事务隔离级别默认的锁机制，如果使用了自定义的锁，那就另当别论。

重点：一般事务使用的是悲观锁（具有排他性）。

锁是事务获取资源的一种控制资源，用于保护数据资源。放置其他事务对数据进行冲突或不兼容访问。

排他锁：当试图修改数据时，事务会为所依赖的数据资源请求排他锁。一旦授予，事务将一直持有排他锁，直至事务完成。

共享锁：当试图读取数据时，事务默认会为所依赖的数据资源请求共享锁，读操作一完成，就立即释放资源上的共享锁。这种模式下，多个事务可以同时持有同一资源上的共享锁。

事务之间的相互制约关系就是锁的兼容性。

数据库事务

数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。

事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。

通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。

一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。

事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

可看做：事务就是一段sql 语句的批处理，但是这个批处理是一个atom（原子），不可分割，要么都执行，要么回滚（rollback）都不执行。

事务的ACID特性(四种属性)

A(Atomicity)原子性

事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。

C(Consistency)一致性

事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。

I(Isolation)隔离性

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

D(Durability)持久性

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

事务的ACID特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的。数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务更新数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。

完整的事务结构

BEGIN a transaction;//设置事务的起始点

COMMIT a transaction;//提交事务，使事务提交的数据成为持久不可更改的部分

ROLLBACK a transaction;//撤销一个事务，回滚，使之成为事务开始前的状态

SAVE a transaction;//建立标签，用作部分回滚，使之恢复到标签初的状态

为什么要加锁？

加锁是为了防止【不同的线程】访问【同一共享资源】造成混乱。

打个比方：人是不同的线程，卫生间是共享资源
你在上洗手间的时候肯定要把门锁上吧，这就是加锁，只要你在里面，这个卫生间就被锁了，只有你出来之后别人才能用。想象一下如果卫生间的门没有锁会是什么样？

什么是加锁粒度呢？

所谓加锁粒度就是你要锁住的范围是多大。

比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。

怎样才算合理的加锁粒度呢？

其实卫生间并不只是用来上厕所的，还可以洗澡，洗手。这里就涉及到优化加锁粒度的问题。
你在卫生间里洗澡，其实别人也可以同时去里面洗手，只要做到隔离起来就可以，如果马桶，浴缸，洗漱台都是隔开相对独立的，实际上卫生间可以同时给三个人使用，
当然三个人做的事儿不能一样。这样就细化了加锁粒度，你在洗澡的时候只要关上浴室的门，别人还是可以进去洗手的。如果当初设计卫生间的时候没有将不同的功能区域划分隔离开，就不能实现卫生间资源的最大化使用。这就是设计架构的重要性。

并发编程中的三个概念

1.原子性：即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

2.可见性：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

3.有序性：即程序执行的顺序按照代码的先后顺序执行。

什么情况下会造成死锁

所谓死锁:
是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.
此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程.
表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB.

不考虑事务的隔离性，会发生的几种问题：

1，脏读

脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。例如：用户A向用户B转账100元，对应SQL命令如下

update account set money=money+100 where name=’B’;  (此时A通知B)

update account set money=money - 100 where name=’A’;

当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。

2，不可重复读

不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。

不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……

3，虚读(幻读)

幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

MySQL数据库的四种隔离级别：

① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。

② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。

③ Read committed (读已提交)：可避免脏读的发生。

④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。

mysql数据库引擎：

mysql大概有下面几个数据库引擎和对应的锁级别：

MyISAM引擎：使用的是表级锁。理解为锁住整个表，可以同时读，写不行。

MEMORY/heap：使用的是表级锁。理解为锁住整个表，可以同时读，写不行。

BDB：使用的是页级锁，它也支持表级锁。一次锁定相邻的一组记录。

InnoDB：使用的是行级锁，它也支持表级锁。单独的一行记录加锁。

MyISAM与InnoDB的区别

InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。

基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。

mysql锁的级别

mysql锁的级别分为三类：页级锁，表级锁，行级锁。

1）表级锁：开销小，加锁快；不会出现死锁；
锁定粒度大，发生锁冲突的概率最高，并发度最低。
分为表共享读锁（共享锁）与表独占写锁（排他锁）。

2）行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。行级锁分为共享锁和排他锁。

3）页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

这里我们主要讨论InnoDB存储引擎，也谈论的是行级锁，一般的在秒杀系统中我们会对商品库存使用行级锁，因为秒杀的时候库存是一个很重要的数据，我们在创建数据库的表时可能会出现下面这样的设置：

ENGINE = InnoDB AUTO_INCREMENT=10 DEFAULT CHARACTER SET = utf8 comment='用户表'
//InnoDB : 数据库引擎	，支持事务
//AUTO_INCREMENT：自增的初始值，默认地，AUTOINCREMENT 的开始值是 1，每条新记录递增 1。

将引擎设置为InnoDB，InnnoDB与其他引擎的不同：一是支持事务（TRANCSACTION），二是采用了行级锁。