先来个提示,此文章是我在学习MySql的过程中看了很多的文章和博客,多的我都数不过来了,之后自己总结或者摘抄一部分,最完整的借鉴的博客(https://www.cnblogs.com/chenqionghe/articles/4845693.html)非常感谢
我自己写出来的总结感觉对我自己有用还是盲点的地方,缺少的地方请见谅
MySQl用的数据结构是B+树数据结构,而oracle用的是B树数据结构,稍微说一点,不是重点
首先你肯定要知道MySql用的是B+树数据结构,但是B+树结构也是有区别的,比如这两个搜索引擎下的B+树的结构就有相同和区别:
区别:就在那个叶子节点的data域
MyIsam不支持事务,但是它的操作是原子的(要不执行,要不不执行,没有执行一半的情况,可以有效避免A在修改数据时因为种种原因停下了,而这时数据修改了一半,这就会影响后面读取这个的数据操作)
InnoDb支持ACID事务,支持事务的四种隔离(重点)
事务的四种属性:
对于串行处理不会发生并发事故,但是太浪费资源和等待时间了,所以并发提高了数据的利用率,提高了数据库的吞吐量,支持更多的人操作而不用浪费时间在等待上,但是有好处就有坏处,并发操作带来了很多问题:
隔离级别/读数据一致性及允许的并发副作用 | 读数据一致性 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|---|
未提交读(Read uncommitted) | 最低级别,只能保证不读取物理上损坏的数据 | 是 | 是 | 是 |
已提交读(Read committed) | 语句级 | 否 | 是 | 是 |
可重复读(Repeatable read) | 事务级 | 否 | 否 | 是 |
可序列化(Serializable) | 最高级别,事务级 | 否 | 否 | 否 |
上面的四种隔离级别,数据库的事务隔离级别越高,并发操作带来的后遗症就会越小,但是付出的代价就会越大,还是那句老话,有失就有得,
事务隔离的本质就是把事务在一定程度上“串行”话,这与“并发”是有一定的矛盾的,不同应用对事务的隔离级别的要求不一样,不要所有的应用都用最高级,那代价就太大了,
比如有的应用对幻读和不可重复读没有什么敏感,更注重数据并发访问能力,
根据隔离级别的特点合理利用才是正确的,要不事务为什么出现四种隔离级别而不是一种
当然上面说的隔离级别是MySQL的,oracle不一定全有这四种
不要以为是表级锁就认为在操作时不允许再让别的进程进行操作
MySql表级锁有两种模式:
看这两个锁的英文其实大家也都懂了,和大部分的读写锁差不多,对于读操作允许多个读操作一起进行,但是不能有写操作,在有写操作时不能有多余的读操作和写操作,
所以可见,MyISAM表的读操作不会阻塞其他用户对同一个表的读请求,但会阻塞对同一个表的写请求,读和写属于串行,写和写也是串行,读和读是并行。
如何加表锁
在执行查询语句(select)之前会自动添加读锁
在执行修改,插入,删除之前会自动添加写锁
知道什么是重点了吧,是“自动”,不用自己操作,
当然也可以显示加锁,一般是为了模拟事务操作,实现实现对某一时间点多个表的一致性读取。例如,有一个订单表orders,其中记录有订单的总金额total,同时还有一个订单明细表order_detail,其中记录有订单每一产品的金额小计subtotal,假设我们需要检查这两个表的金额合计是否相等,可能就需要执行如下两条SQL:
SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;
有可能在查第二条语句时数据发生变化了,这样就有可能产生错误的结果,所以可以这样
LOCK tables orders read local,order_detail read local;
SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;
Unlock tables;
显示加锁,需要说明的一点 Lock tables后加了local选项,这个就是一开始说的那个警示,
也支持并发锁
并发锁
在一定条件下,MyISAM也支持查询和操作的并发进行。
MyISAM存储引擎有一个系统变量concurrent_insert,专门用以控制其并发插入的行为,其值分别可以为0、1或2。
可以利用MyISAM存储引擎的并发插入特性,来解决应用中对同一表查询和插入锁争用。例如,将concurrent_insert系统变量为2,总是允许并发插入;同时,通过定期在系统空闲时段执行OPTIONMIZE TABLE语句来整理空间碎片,收到因删除记录而产生的中间空洞。
MyISAM的锁调度
前面讲过,MyISAM存储引擎的读和写锁是互斥,读操作是串行的。那么,一个进程请求某个MyISAM表的读锁,同时另一个进程也请求同一表的写锁,MySQL如何处理呢?答案是写进程先获得锁。不仅如此,即使读进程先请求先到锁等待队列,写请求后到,写锁也会插到读请求之前!这是因为MySQL认为写请求一般比读请求重要。这也正是MyISAM表不太适合于有大量更新操作和查询操作应用的原因,因为,大量的更新操作会造成查询操作很难获得读锁,从而可能永远阻塞。这种情况有时可能会变得非常糟糕!幸好我们可以通过一些设置来调节MyISAM的调度行为。
虽然上面3种方法都是要么更新优先,要么查询优先的方法,但还是可以用其来解决查询相对重要的应用(如用户登录系统)中,读锁等待严重的问题。
另外,MySQL也提供了一种折中的办法来调节读写冲突,即给系统参数max_write_lock_count设置一个合适的值,当一个表的读锁达到这个值后,MySQL变暂时将写请求的优先级降低,给读进程一定获得锁的机会。
这也是,不要以为是行级锁以为只是锁行,它也能锁表
先来重点:
InnoDB行锁是通过索引上的索引项来实现的,这一点MySQL与Oracle不同,后者是通过在数据中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味者:只有通过索引条件检索数据****,InnoDB才会使用行级锁,否则 ,InnoDB将使用表锁!
在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。
上面的一定要多看几遍,没有索引项是启动不了行级锁的,它会启动表锁
InnoDb有两种类型
这两个锁很像读锁和写锁,可以这么理解
另外,为了允许行锁和表锁共存,实现多粒度锁机制,InnoDB还有两种内部使用的意向锁(Intention Locks),这两种意向锁都是表锁。
这个很像MyISAM的表共享表锁和表独占写锁
当前锁模式/是否兼容/请求锁模式 | x | IX | S | IS |
---|---|---|---|---|
X | 冲突 | 冲突 | 冲突 | 冲突 |
IX | 冲突 | 兼容 | 冲突 | 兼容 |
S | 冲突 | 冲突 | 兼容 | 兼容 |
IS | 冲突 | 兼容 | 兼容 | 兼容 |
如果一个事务请求的锁模式与当前的锁兼容,InnoDB就请求的锁授予该事务;反之,如果两者两者不兼容,该事务就要等待锁释放。
重点: 意向锁是InnoDB自动加的,不需用户干预。
事务可以通过以下语句显示给记录集加共享锁或排锁。
说明 加共享锁是用 lock in share mode ,纯粹的select 是不拿锁的,查询是用 一致性非锁定读 来处理.
当我们用范围条件而不是相等条件检索数## 标题据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制不是所谓的间隙锁( Next-Key锁)。
举例来说,假如emp表中只有101条记录,其empid的值分别是1,2,…,100,101,下面的SQL:
SELECT * FROM emp WHERE empid > 100 FOR UPDATE
是一个范围条件的检索,InnoDB不仅会对符合条件的empid值为101的记录加锁,也会对empid大于101(这些记录并不存在)的“间隙”加锁。
InnoDB使用间隙锁的目的,一方面是为了防止幻读,以满足相关隔离级别的要求,对于上面的例子,要是不使用间隙锁,如果其他事务插入了empid大于100的任何记录,那么本事务如果再次执行上述语句,就会发生幻读;另一方面,是为了满足其恢复和复制的需要。有关其恢复和复制对机制的影响,以及不同隔离级别下InnoDB使用间隙锁的情况。
很显然,在使用范围条件检索并锁定记录时,InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入,这往往会造成严重的锁等待。因此,在实际开发中,尤其是并发插入比较多的应用,我们要尽量优化业务逻辑,尽量使用相等条件来访问更新数据,避免使用范围条件。
是不是很矛盾,上文说InnoDb可以用表级锁,但是我们知道InnoDb是行级锁的引擎
那就仔细看下文吧
对于InnoDb表,在绝大部分情况下都应该使用行级锁,因为事务和行锁往往是我们选择InnoDb表的理由,要不为什么不使用MyISAM表呢,但是凡事都有例外,有时候InnoDb表也需要用到表级锁
需要说明的是
例如,如果需要写表t1并从表t读,可以按如下做:
SET AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2 READ, ...;
[do something with tables t1 and here];
COMMIT;
UNLOCK TABLES;
因为MyISAM是表锁,一次性获得所需的全部锁,要不全满足,要不等待,所以是不会出现死锁的,但是在InnoDb中,除单个SQL组成的事务外,锁是逐步获得的,这就决定了InnoDb发生死锁是可能的
如果不知道死锁是什么意思,那请百度
发生死锁后,InnoDB一般都能自动检测到,并使一个事务释放锁并退回,另一个事务获得锁,继续完成事务。
但在涉及外部锁,或涉及锁的情况下, InnoDB并不能完全自动检测到死锁, 这需要通过设置锁等待超时参数innodb_lock_wait_timeout来解决。需要说明的是,这个参数并不是只用来解决死锁问题,在并发访问比较高的情况下,
如果大量事务因无法立即获取所需的锁而挂起,会占用大量计算机资源,造成严重性能问题,甚至拖垮数据库。我们通过设置合适的锁等待超时阈值,可以避免这种情况发生。
通常来说,死锁都是应用设计的问题,通过调整业务流程、数据库对象设计,事务大小,以及访问数据库的SQL语句,绝大部分都是可以避免的,下面就介绍几种死锁的常用方法
尽管通过上面的设计和优化等措施,可以大减少死锁,但死锁很难完全避免。因此,在程序设计中总是捕获并处理死锁异常是一个很好的编程习惯。
如果出现死锁,可以用SHOW INNODB STATUS命令来确定最后一个死锁产生的原因和改进措施。
总结
对于MyISAM的表锁,主要有以下几点
(1)共享读锁(S)之间是兼容的,但共享读锁(S)和排他写锁(X)之间,以及排他写锁之间(X)是互斥的,也就是说读和写是串行的。
(2)在一定条件下,MyISAM允许查询和插入并发执行,我们可以利用这一点来解决应用中对同一表和插入的锁争用问题。
(3)MyISAM默认的锁调度机制是写优先,这并不一定适合所有应用,用户可以通过设置LOW_PRIPORITY_UPDATES参数,或在INSERT、UPDATE、DELETE语句中指定LOW_PRIORITY选项来调节读写锁的争用。
(4)由于表锁的锁定粒度大,读写之间又是串行的,因此,如果更新操作较多,MyISAM表可能会出现严重的锁等待,可以考虑采用InnoDB表来减少锁冲突。
对于InnoDB表,主要有以下几点
(1)InnoDB的行销是基于索引实现的,如果不通过索引访问数据,InnoDB会使用表锁。
(2)InnoDB间隙锁机制,以及InnoDB使用间隙锁的原因。
(3)在不同的隔离级别下,InnoDB的锁机制和一致性读策略不同。
(4)MySQL的恢复和复制对InnoDB锁机制和一致性读策略也有较大影响。
(5)锁冲突甚至死锁很难完全避免。
在了解InnoDB的锁特性后,用户可以通过设计和SQL调整等措施减少锁冲突和死锁,包括: