Mysql锁基础

Mysql锁基础,第1张

【表锁】

偏向MyISAM存储引擎,开销小,加锁快:无死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。

MySQL的表级锁有两种模式:表共享读锁(Table Read Lock)表独占写锁(Table Write Lock>

锁类型可否兼容读锁写锁
读锁
写锁

结论:
结合上表,所以对MylSAM表进行 *** 作,会有以下情况:

  1. 对MylISAM表的读 *** 作〈加读锁),不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求。只有当读锁释放后,才会执行其它进程的写 *** 作。
  2. 对MyISAM表的写 *** 作(加写锁),会阻塞其他进程对同一表的读和写 *** 作,只有当写锁释放后,才会执行其它进程的读写 *** 作。

简而言之:就是读锁会阻塞写,但是不会堵塞读。而写锁则会把读和写都堵塞

【如何分析表锁定】

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

 show status like 'table%";

这里有两个状态变量记录MySQL内部表级锁定的情况,两个变量说明如下:

Table_locks_immediate:
产生表级锁定的次数,表示可以立即获取锁的查询次数,每立即获取锁值加1;

Table_locks_waited:
出现表级锁定争用而发生等待的次数(不能立即获取锁的次数,每等待一次锁值加1),此值高则说明存在着较严重的表级锁争用情况;

此外,Myisam的读写锁调度是写优先,这也是myisam不适合做写为主表的引擎。因为写锁后,其他线程不能做任何 *** 作,大量的更新会使查询很难得到锁,从而造成永远阻塞

【行锁】

偏向InnoDB存储引擎,开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION),二是采用了行级锁

行锁:在当前事务A内 *** 作的行均被上锁、不影响事务B *** 作A范围外的行,若事务B *** 作A被锁定的行将会造成阻塞、直至事务A事务提交事务B才能继续 *** 作。

--锁定一行记录
select * from table_a where a = 8 for update;

【行锁特殊情况】

  1. 索引失效导致行锁变表锁 varchar类型条件不加单引号
  2. 尽可能减少条件范围,避免间隙锁(已知a=2的数据不存在,事务A *** 作范围 1 < a < 6,事务B插入a = 2 的数据会阻塞的现象)

Innodb存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些,但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候,Innedb的整体性能和MyISAM相比就会有比较明显的优势了。
但是,Innodb的行级锁定同样也有其脆弱的一面,当我们使用不当的时候,可能会让Innodb的整体性能表现不仅不能比MyISAM高,甚至可能会更差。

【如何分析行锁定】

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like 'innodb_row_lock%';

对各个状态量的说明如下:

Innodb_row_lock_current_waits:当前正在等待锁定的数量;
Innodb_row_lock_time:从系统启动到现在锁定总时间长度;
Innodb_row_lock_time_avg:每次等待所花平均时间;
Innodb_row_lock_time_max:从系统启动到现在等待最常的一次所花的时间;
lnnodb_row_lock_waits:系统启动后到现在总共等待的次数;

比较重要的参数:

lnnodb_row_lock_time_avg(等待平均时长),Innodb_row_lock_waits(等待总次数>
lnnodb_row_lock_time(等待总时长)这三项。
尤其是当等待次数很高,而且每次等待时长也不小的时候,我们就需要分楣系统中为什么会有如此多的等待,然后根据分析结果着手指定优化计划。

【一般建议】

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

【悲观/乐观锁】

悲观锁:悲观的认为一定会产生竞争事务开始直接加锁、使用for update 直接锁定行再 *** 作

乐观锁:乐观的认为不会发生竞争事务开始不加锁、但是使用CAS理论(Compare And Swap)比较并更新、使用加版本号的方法对比更新。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/759248.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-01
下一篇 2022-05-01

发表评论

登录后才能评论

评论列表(0条)

保存