mysql锁

一：innodb行锁是如何实现： 1：innodb的行锁是通过给索引上的索引项加锁来实现的 2：通过索引进行数据检索，innodb才会使用行级锁，否则innodb会使用表锁（锁住索引的所有记录） 二：innodb算法之锁（临键锁、间隙锁、记录锁）：都是根据innodb存储引擎 1：临键锁（Next-Key Locks）：当SQL执行按照索引进行数据的检索时，且查询条件为范围查询（between 、and、 >、<等），且有数据命中时，该SQL语句加上的行锁为Next-Key Locks 具体实现：锁住命中记录区间 + 下一个区间（左开右闭） 临键锁如下图所示： 2:间隙锁（Gap-Lock）：范围查询或者是等值查询，且记录不存在，当记录不存在，临键锁退化成GAP锁，且gap锁之间不冲突， 锁住的范围是左开右开区间 间隙锁如下图所示： 3：记录锁（Record-Lock） 当SQL执行按照唯一性（primary key, unique ）索引进行数据的检索时，且查询条件等值匹配且查询的数据命中存在，这时SQL语句加上的锁为记录锁 具体实现：锁住具体索引的索引项 记录锁如下图所示 来源： https://www.cnblogs.com/jelly12345/p/11898737.html

MySQL 原理篇 MySQL 索引机制 MySQL 体系结构及存储引擎 MySQL 语句执行过程详解 MySQL 执行计划详解 MySQL InnoDB 缓冲池 MySQL InnoDB 事务 MySQL InnoDB 锁 MySQL InnoDB MVCC MySQL InnoDB 实现高并发原理 MySQL InnoDB 快照读在RR和RC下有何差异 数据准备： /* SQLyog Ultimate v12.09 (64 bit) MySQL - 5.6.17 : Database - test ********************************************************************* */ /*!40101 SET NAMES utf8 */; /*!40101 SET SQL_MODE=''*/; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE

> 文章首发于： clawhub.club 1、概念 死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种相互等待的现象。 具体的介绍可以参考我以前写的一篇文章： 【并发编程挑战】死锁 2、死锁检测 以下文字全部摘抄整理自《MySQL技术内幕 InnoDB存储引擎 第二版》，在InnoDB存储引擎中，采用wait-for graph(等待图)的方式来进行死锁检测。 wait-for graph要求数据库保存一下两种信息： 锁的信息链表 事务等待链表 通过上述链表可以构造出一张图，而在这个图中若存在回路，就代表存在死锁，因此资源间相互发生等待。在wait-for graph中，事务为图中的节点。在图中，事务T1指向T2定义为： 事务T1等待事务T2所占用的资源 事务T1发生在事务T2后面 事务T2所占用的资源不会被强制剥夺 下面通过一个例子分析，当前事务与锁的状态如下图： 由图可知： 事务等待列表中有4个事务，在wait-for graph中对应4个节点。 事务t2对row1(行)占用x锁（独占锁），事务t1对row2(行)占用s锁（共享锁） 事务t1等待事务t2所占用的row1资源，因此在wait-for graph中有条边从节点t1指向t2。 事务t2等待事务t1、t4所占用的row2资源，t4对于row2占用s锁。故存在t2指向t1、t4的边。 同样

环境 MySQL5.5 现象 A.数据更新或新增后数据经常自动回滚。 B.表操作总报 Lock wait timeout exceeded 并长时间无反应 解决方法 A.应急方法： show processlist; kill掉出现问题的进程 B.根治方法： select * from innodb_trx 查看有是哪些事务占据了表资源。 C.我的方法：设置MySQL锁等待超时 innodb_lock_wait_timeout=50 ，autocommit=on 该类问题导致原因 据我分析,Mysql的 InnoDB存储引擎是支持事务的，事务开启后没有被主动Commit。导致该资源被长期占用，其他事务在抢占该资源时，因上一个事务的锁而导致抢占失败！因此出现 Lock wait timeout exceeded 接下来是转载的内容 转载: http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html MySQL 5.5 -- innodb_lock_wait 锁 等待 记得以前，当出现：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction， 要解决是一件麻烦的事情 ； 特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁

一、基本概念 　　从操作的类型上来看，分为读锁和写锁： 　　　　读锁：共享锁，对同一份数据，多个读操作可以同时进行且相互间不影响 　　　　写锁：排它锁，独占资源。在当前操作未完成之前，其他写操作必须等待。读操作不影响。 　　　　　　　排它锁作用于innodb，且必须在事务块中执行。在进行事务操作时，for update会对结果集中的每一行数据加排它锁，其他线程对于结果集中的数据进行修改操作，全部阻塞。 　　从锁数据的细粒度上来看，分为行锁和表锁。 二、测试 　　测试环境：mysql 5.5.6、Navicat for mysql。 　　新建表： CREATE TABLE `tb_user` ( `id` int(10) NOT NULL AUTO_INCREMENT, `name` varchar(10) DEFAULT NULL, `password` varchar(10) DEFAULT NULL, `sex` char(1) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 　　开启两个查询会话，模拟多请求。 　　1、表锁 　　　　锁的粒度偏大，开销小，锁表快，但是发生锁竞争的概率特别高，并发度低。 　　　　对于更新update、delete

锁 一、概念 　　锁是计算机协调多个进程或线程访问某一个资源的机制。在数据库中，除传统的计算资源（CPU、RAM、IO）的争用意外，数据也是一种许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问的一个重要因素。从这个角度来说，锁对数据库尤其重要，也更加复杂。本文就以MyISAM和InnoDB两个引擎来说明锁的问题； 二、MySQL锁概述 　　相对其他数据库而言，MySQL的锁机制比较简单，其中最为显著的特点是不同的引擎具有不同的锁。比如MyISAM和InnoDB分别采用表锁、行锁，但是InnoDB也支持表锁，默认情况下采用行锁； 三、MySQL表锁和行锁对比 锁的名称 开销 加锁速度 死锁 粒度 并发性能 表锁 С 快 不会出现 大 最低 行锁 大 慢 出现 С 最高 从锁的角度来说表锁适合查询为主，只有少量按索引条件更新数据的应用；行锁适合于大量按索引条件来并发更新少量的数据，同时又有并发查询的应用； MyISAM表锁 　　可以通过table_locks_waited和table_locks_immediate来分析系统表锁的争夺； 如果table_locks_waited的值比较高的话，则说明存在较高的表锁争夺。 二、表锁的锁模式 　　表级锁有两种方式：读锁和写锁，锁模式的兼容性如下: 由上表可见

　　间隙锁（Gap Lock）：锁加在不存在的空闲空间，可以是两个索引记录之间，也可能是第一个索引记录之前或最后一个索引之后的空间。 　　innodb_locks_unsafe_for_binlog，这个参数默认值是OFF， 也就是启用间隙锁， 他是一个bool值， 当值为true时表示disable间隙锁。 　　举个例子： 　　表testLock,有两个属性id,和name.有如下数据。 　　开启一个会话： session 1 sql> set autocommit=0; ##取消自动提交 sql> delete from testLock where id = ‘6’; 　　在开启一个会话： session 2 sql> set autocommit=0;##取消自动提交 sql> insert into testLock(id,name) values(‘6’,’hahaha’); sql> delete from testLock where id = ‘6’; sql> insert into testLock(id,name) values(‘6’, ‘hahaha’); 　　这个时候最后一条语句：insert into testLock(id,name) values(‘6’, ‘hahaha’); 执行时就会爆出死锁错误。因为删除id = 6这条记录的时候

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 1.2 wait-for graph原理 1.2.1 锁与索引的关系 id: bigint token: varchar(30) message: varchar(4096) 1）delete from msg where id=2； 2）delete from msg where token=’ cvs’; 3）delete from msg where message=订单号是多少’； 1.2.2 锁与隔离级别的关系 1）未提交读（Read uncommitted）； 2）已提交读（Read committed（RC））； 3）可重复读（Repeatable read（RR））； 4）可串行化（Serializable）。 我们较常使用的是RC和RR。 RC级别下尽管加了行锁，但还是避免不了幻读。 RR隔离级别 可以避免幻读发生，怎么实现？当然需要借助于锁了！ gap锁（间隙锁） 。 3 死锁成因 3.1不同表相同记录行锁冲突 3.2相同表记录行锁冲突 3.3不同索引锁冲突 3.4 gap锁冲突 4 如何尽可能避免死锁 1）以固定的顺序访问表和行。比如对第2节两个job批量更新的情形

表总体上分为三种： 　　1、表锁 Myisam　　开销小，并发低，加锁快，不会出现死锁问题；锁粒度大，发生锁冲突的概率最高。 　　3、页面锁　　　　　 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。（不常用） 共享锁（读锁）/排它锁（写锁） 　　共享锁又叫读锁，是读取操作创建的锁。其他用户可以同步读取数据，但是不能够写数据。 　　排它锁又叫写锁，是更新操作创建的锁。其他用户不可以同步读取数据更不能写数据。 MyIsam锁模式： 　　MyIsam引擎在执行查询语句前，会自动给涉及到的表添加读锁；在更新操作前会自动给涉及到的表加写锁。 　　a、对MyIsam中的表进行读取操作，其他用户可以进行读取，但是不能修改； 　　b、对MyIsam中的表进行更新操作，其他用户不能进行读取，更不能进行操作。 InnoDb锁模式： 　　对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；对于一般的Select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。 共享锁： SELECT ... LOCK IN SHARE MODE; 排他锁： SELECT ... FOR UPDATE; InnoDb是根据索引加行锁的，如果没有索引的话依然是加表锁。因此如果多行数据都使用同一个索引，会出现锁冲突 　　

最近开发中遇到一些问题，这里记录下Mysql中的两种表级别的锁。 读锁： 所有的会话 只能进行SELECT语句查询 lock tables table_name READ; 写锁： 只有当前会话 能增删改查， 其他会话无法任何操作 lock tables table_name WRITE 下面是个简单测试： 首先测试Write 下面先开启一个客户端进行如下操作： mysql> show open tables from numtest; +----------+-------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-------+--------+-------------+ | numtest | num | 1 | 0 | +----------+-------+--------+-------------+ 1 row in set (0.00 sec) mysql> lock tables num WRITE; Query OK, 0 rows affected (0.00 sec) mysql> show open tables from numtest; +----------+-------+--------+-------------+ |