mysql锁

一.分布式锁要解决的问题 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 这把锁要是一把可重入锁（避免死锁） 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条） 这把锁最好是一把公平锁（根据业务需求考虑要不要这条） 有高可用的获取锁和释放锁功能 获取锁和释放锁的性能要好 二.基于数据库实现原理 1.新建锁表记录 CREATE TABLE `methodLock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名', `desc` varchar(1024) NOT NULL DEFAULT '备注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成', PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT

全局锁 典型使用场景是全库逻辑备份。 在备库的时候，对于使用innodb的引擎的数据库来说，在mysqldump操作时，使用--single-transaction 参数，利用一致性视图的原理，在备库 的过程中并不会影响数据库的读写； 表锁 语法是 lock tables t read/write unlock tables; 线程a 执行 lock tables t read; 线程a 可读,写 会报错； 线程b 可读，写会阻塞； 线程a 执行lock tables write; 线程a 可读，可写 线程b 读会阻塞，写会阻塞； 另外一种表锁，是mdl-metedata lock，元数据锁 读锁：表的增删改 写锁：mdl语句 读读不阻塞；读写阻塞；写写阻塞 所以修改表结构容易导致整个库挂掉，就是因为写锁阻塞了正常的数据库增删改，线程越积越多 解决方案就是加过期时间 比如 alter table t notwait add f alter table t wait n add f 来源： https://www.cnblogs.com/qihongfeiblog/p/11421815.html

　　关键词 ：行锁、表锁、乐观锁、悲观锁、gap锁、next-key 一、行锁与表锁： 1、表锁： 锁定粒度是表 （1）意向共享锁（IS）：事务如果想要读某一个数据行，那么必须取得该表的IS锁。 （2）意向排他锁（IX）：事务如果想要对某一个数据行进行更新操作，那么必须先取得该表的IX锁。 （3）加锁方式： 意向共享锁（IS）：LOCK table tableName read; 意向排他锁（IX）：LOCK table tableName write; 2、行锁（记录锁）--共享锁和排他锁： 锁定粒度是数据行 （1）共享锁（读锁、S锁）：事务在读某一个数据行时，如果给当前数据行加上S锁，那么此时只允许其他事务读取当前数据行，而禁止其他事务对当前数据行进行写操作。 （2）排他锁（写锁、X锁）：事务在对某一个数据行进行更新操作时，如果给当前数据行加上X锁，那么会禁止其他事务对相同的数据行进行读或者写操作。 （3）InnoDB引擎下的行锁分析： 　　①对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及的数据集加排他锁（X)； 　　②对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。 共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 排他锁

锁的类型 共享锁(S) 共享锁可以被多个事务持有，事务T1获取了行r的共享锁，那么事务T2也可以获得行r的共享锁，但是获取不到事务T1的排它锁 显示的加共享锁：select * from xx lock in share mode; 排它锁(X) 排他锁只能被一个事务持有，事务T1持有了行r的排它锁，那么事务T2获取不到行r的排它锁，也获取不到行r的共享锁 显式的加排它锁：select * from xx for update; S X S 兼容 不兼容 X 不兼容 不兼容 创建一张测试表a,id是主键，a2为唯一索引，a3为普通所以 CREATE TABLE `a` ( `id` int(11) NOT NULL AUTO_INCREMENT , a1 int(11) NOT NULL , a2 int(11) not NULL, a3 int(11) not null, PRIMARY KEY (`id`), unique key uniq_a2(a2), index idx_a3(a3) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; insert into a(a1,a2,a3) values(1,2,3),(2,4,6),(3,6,12); 事务1获取共享锁，事务2获取排它锁，事务2将获取失败 事务1 事务2 start

本文主要记录InnoDB存储引擎中锁的关键点，下篇文章通过实例确认加锁的范围。 InnoDB中的锁 1. 锁提供数据完整性和一致性 2. InnoDB行级锁：共享锁（S）和排他锁（X）。 　　为了支持多粒度锁定，InnoDB支持意向锁，该锁允许事务在行锁和表锁同时存在。包括意向共享锁（IS）和意向排他锁（IX）。 　　意向锁将锁定的对象分为多个层次，意味着事务希望在更细粒度上进行加锁，如需要对页上的记录r加X锁，分别需要对数据库、表、页加意向锁IX，最后对记录r加X锁，其中任何一部分导致等待，该操作需要等待粗粒度锁的完成。 3. 锁的查看方式 　　 通过show engine innodb status来查看，其中的transactions片段可以看到事务，其中包括锁等待。 　　在information_schema架构下，有3个表记录了事务和锁相关的信息。分别是 INNODB_TRX,INNODB_LOCKS,INNODB_LOCK_WAITS 。（具体看书或博客） 4. 一致性非锁读 　　非锁定读机制，是InnoDB存储引擎的默认设置，默认 读取不会占用和等待表上的锁 　　InnoDB存储引擎利用 行多版本控制 实现一致性非锁读， 　　当读取的行正在加X锁DELETE或UPDATE时，读操作不会等待锁释放，会读取行的一个 快照数据 　　快照数据是指该行之前版本的数据，其通过

mysql 数据支持表级锁，也支持行级锁，但是myIsam 存储引擎只支持表级锁，innodb存储引擎支持行级锁。 表级锁的使用语法为： 加 表级读锁 lock table t_user（表名） read; 加表级写锁：lock table t_user write; 释放锁：UNLOCK tables; 下面为表级锁的测试样例： 创建两张表如下： 1 CREATE TABLE `t_user` ( 2 `id` int(11) NOT NULL AUTO_INCREMENT, 3 `name` varchar(20) DEFAULT NULL, 4 `age` int(11) DEFAULT NULL, 5 `sex` varchar(20) DEFAULT NULL, 6 PRIMARY KEY (`id`) 7 ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8； 8 9 10 CREATE TABLE `t_account` ( 11 `id` int(11) NOT NULL AUTO_INCREMENT, 12 `NAME` varchar(20) DEFAULT NULL, 13 `money` double DEFAULT NULL, 14 PRIMARY KEY (`id`) 15 ) ENGINE

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。 为了更系统的分析问题，本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 左图那两辆车造成死锁了吗？不是！右图四辆车造成死锁了吗？是！ 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 wait-for graph原理 我们怎么知道上图中四辆车是死锁的？他们相互等待对方的资源，而且形成环路！我们将每辆车看为一个节点

1、flush tables with read lock 全局锁 　　导致全库只读 　　mysqldump-single-transaction (通过repeatable read 隔离级别启动事务) 　　set global read-only 一般用来判断主备库 2、表级锁 　　lock table unlock table 表锁 　　MDL 元数据锁 (开始第一次查询是获取读锁，事务提交时才会释放MDL读锁) 　　小表的DDL语句会导致全库崩溃 　　select * from table 获取MDL读锁 　　alter table add index (a) blocked 等待读锁释放获取MDL写锁 　　后续所有的的操作都会被blocked 3、行级锁（引擎层实现） 　　两阶段锁： 真正查询时使用，提交时释放。 尽量将可能同时操作的语句放到后面 　　死锁，死锁检测 　　　　---innodb_lock_wati_time 50 默认 　　　　---innodb_deadlock_detect on 　　死锁发生的场景 　　　　----并发100线程 同时修改某条记录 会发现cpu100%,但实际更新操作缺很少（这是因为死锁检测耗费了大量cpu） 　　　　----解决方案 将单条记录拆成多条,降低死锁的可能性 　　 　　 ’ 来源： https://www.cnblogs

原因分析： 在高并发的情况下，Spring事物造成数据库死锁，后续操作超时抛出异常。 Mysql数据库采用InnoDB模式，默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s，一旦数据库锁超过这个时间就会报错。 解决方案 1、通过下面语句查找到为提交事务的数据，kill掉此线程即可。 select * from information_schema.innodb_trx kill trx_mysql_thread_id ; 如果kill掉的sql 是update或insert 先保存sql再kill 2、增加锁等待时间，即增大下面配置项参数值，单位为秒（s） innodb_lock_wait_timeout=200 3、优化存储过程,事务避免过长时间的等待 来源： https://www.cnblogs.com/paad/p/11364537.html

加锁规则 加锁规则 案例一：等值查询间隙锁 案例二：非唯一索引等值锁 案例三：主键索引范围锁 案例四：非唯一索引范围锁 案例五：唯一索引范围锁bug 案例六：非唯一索引上存在“等值”的例子 案例七：limit加锁 案例八：一个死锁的例子 总结 间隙锁在可重复读隔离级别下才有效，本篇博文默认是可重复隔离级别 加锁规则 总结为两个“原则”、两个“优化”和一个“bug” 原则1：加锁的基本单位是next-key lock,前开后闭区间； 原则2：查找过程中访问到的对象都会加锁； 优化1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁； 优化2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，nextkeylock 退化为间隙锁； 一个bug:唯一索引上的范围查询会访问到不满足条件的第一个值为止; 以表t为例 CREATE TABLE 't' ( 'id' int ( 11 ) NOT NULL , 'c' int ( 11 ) DEFAULT NULL , 'd' int ( 11 ) DEFAULT NULL , PRIMARY KEY ( 'id' ) , KEY 'c' ( 'c' ) ) ENGINE = InnoDB ; insert into t values ( 0 , 0 , 0 ) , ( 5 , 5 , 5 ) , (