共享锁

锁粒度 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较 表级锁 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现

转自：https://www.cnblogs.com/boblogsbo/p/5602122.html mysql锁机制分为表级锁和行级锁，本文就和大家分享一下我对mysql中行级锁中的共享锁与排他锁进行分享交流。 共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for

关于Java 锁的知识整理与回顾（个人笔记）： 锁有哪些，分别用来干嘛？ Java实现锁有两种方式，synchronized关键字和Lock (1)Lock（可判断锁状态） Lock是基于JDK层面实现。Lock的实现主要有ReentrantLock、ReadLock和WriteLock（引出锁分类：） ①乐观锁/悲观锁： 乐观锁认为读多写少，乐观的认为拿数据时，不会改数据，所以不会上锁，而在更新数据时才会判断有无数据更新。悲观锁悲观的认为，写多，拿数据时先设定数据被修改了，每次在读写数据时都会上锁。 ②公平锁/非公平锁： ReentrantLock在构造函数中提供是否公平锁的初始化方式（默认是非公平锁，就是说可以变成公平锁。即他和synchronized不同之处之一）： public ReentrantLock() { sync = new NonfairSync(); } public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); } 非公平锁不按套路出牌，有可能造成“饥饿”现象，但是它的实际执行效率、吞吐量要高于公平锁。 ③独享锁/共享锁 独享锁是指该锁一次只能被一个线程所持有 (ReentrantLock、 Synchronized)，共享锁反之

独占锁、共享锁、更新锁，乐观锁、悲观锁 1、锁的两种分类方式 （1）从数据库系统的角度来看，锁分为以下三种类型： 独占锁（Exclusive Lock） 　　独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放。 共享锁（Shared Lock） 　　共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。 更新锁（Update Lock） 　　更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定。 （2）从程序员的角度看，锁分为以下两种类型： 悲观锁（Pessimistic Lock） 　　悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此在整个数据处理过程中

MySQL的又一神器-锁，MySQL面试必备 https://segmentfault.com/a/1190000020762791 lock 低一级的是 latch 原文链接：blog.ouyangsihai.cn >> MySQL的又一神器-锁，MySQL面试必备 在看这篇文章之前，我们回顾一下前面的几篇关于MySQL的文章，应该对你读下面的文章有所帮助。 InnoDB与MyISAM等存储引擎对比 面试官问你B树和B+树，就把这篇文章丢给他 MySQL的B+树索引的概念、使用、优化及使用场景 MySQL全文索引最强教程 MySQL的又一神器-锁，MySQL面试必备 1 什么是锁 1.1 锁的概述 在生活中锁的例子多的不能再多了，从古老的简单的门锁，到密码锁，再到现在的指纹解锁，人脸识别锁，这都是锁的鲜明的例子，所以，我们理解锁应该是非常简单的。 再到MySQL中的锁，对于MySQL来说，锁是一个很重要的特性，数据库的锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性，这样才能保证在高并发的情况下，访问数据库的时候，数据不会出现问题。 1.2 锁的两个概念 在数据库中，lock和latch都可以称为锁，但是意义却不同。 Latch 一般称为 闩锁 （轻量级的锁），因为其要求锁定的时间必须非常短。若持续的时间长，则应用的性能会非常差，在InnoDB引擎中

文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。 锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中数据其实是一种供大量用户共享的资源，所以在并发访问时我们需要保证数据的一致性和有效性，而锁冲突是影响数据库并发性能最关键的因素之一。所以本篇文章主要讨论Mysql中锁机制的特点。Mysql的锁机制包含多种：行锁，表锁，读锁，写锁等，其实就是使用不同的存储引擎会支持不同的锁机制。而我主要是针对InnoDB存储引擎下的7种类型的锁进行介绍。 InnoDB引擎锁类型： 共享/排它锁 记录锁 间隙锁 临键锁 自增锁 意向锁 插入意向锁 MySQL中InnoDB存储引擎与MyISAM存储引擎锁机制其实有两个比较显著的不同点： InnoDB支持事务操作。 InnoDB默认采用行级锁。 InnoDB锁机制实现原理 InnoDB存储引擎其实是通过给索引上的索引项添加锁，也正是由于给索引项加锁，所以只有通过索引条件查询数据，InnoDB引擎才会选择使用行级锁，否则会使用表锁。行级锁与表级锁本身有许多不同之处，事务的引入也带来了一些新问题。 事务 说到事务，四个最基本的特性我想大多数人再清楚不过了： 原子性: 事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性：在事务开始和完成时，数据都必须保持一致状态。 隔离性

事务的基本定义 　　事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。 事务的属性 　　谈到事务一般都是以下四点属性： 原子性（Atomicity） 　　原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 一致性（Consistency） 　　事务前后数据的完整性必须保持一致。 隔离性（Isolation） 　　事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。 持久性（Durability） 　　持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 事务的隔离级别 　　事务的隔离是为了解决多事务执行过程中产生的 脏读、不可重复读、幻读 等问题。 　　事务从低到高的四种隔离级别（其中隔离级别越严格，安全性越高，但数据库的并发性能也就越低）： Read Uncommitted（读未提交） 　　 一个事务可以读取另一个未提交事务（有修改操作）的数据。 会出现脏读。 Read committed（读已提交）[比较常见] 　　 一个事务要等另一个事务（有修改操作）提交后才能读取数据。 若有事务对数据进行更新（UPDATE）操作时

最近做一个统计；需要把一个字段(存放数据是json)里某一个数字加1 然后在修改该字段；当时就那么一写最后发现该数据和明细对不上； 其实这个应该是并发引起的，先select 在update 这样写其实会出现一些问题 参考篇文章 ###第一种解决方案 事务，即用一个事务来包裹上面的SELECT+UPDATE操作+写共享锁。 读共享锁是通过下面这样的SQL获得的： SELECT * FROM parent WHERE NAME = 'Jones' LOCK IN SHARE MODE; 如果事务A获得了先获得了读共享锁，那么事务B之后仍然可以读取加了读共享锁的行数据，但必须等事务A commit或者roll back之后才可以更新或者删除加了读共享锁的行数据。 如果事务A先获得了某行的写共享锁，那么事务B就必须等待事务A commit或者roll back之后才可以访问行数据。 SELECT counter_field FROM child_codes FOR UPDATE; UPDATE child_codes SET counter_field = counter_field + 1; ###第二种解决方案 乐观锁,上面是一种观锁机制，而且 SELECT...FOR UPDATE 方式也不太常用 SELECT counter_field FROM child_codes FOR

并发、事务和锁 并发，在操作系统中，是指一个很短的时间段中有几个程序都处于已启动运行到运行完毕之间，并发程序之间有相互制约关系，直接制约体现为一个程序需要另一个程序的计算结果，间接制约体现为多个程序竞争同一资源，如处理机、缓冲区、数据等。在数据库系统中，并发主要是指资源的争用，当两个进程同时在访问或更新同一个数据时，产生资源的争用，资源争用会引起一系列的问题，比如数据不一致、查询阻塞、死锁等。 一，并发模式 在数据库系统中，当多个进程访问同一资源时，默认情况下，SQL Server会通过各种类型的锁来协调资源的访问，确保在并发环境下数据保持一致的状态。而锁的作用范围是在事务中，事务建立在并发模式下。并发模式控制当发生读写冲突时，数据应该如何处理以保证数据的一致性。注意，写和写之间永远冲突。 1，乐观并发模式 对于乐观并发模式，SQL Server假设只有少量的冲突发生，默认的机制是使用快照技术，在写进程完成修改数据之前，先把数据的行版本保存到tempdb中。由于数据的旧数据已经保存，读进程可以直接读取已经保存的行版本，而不会受到写进程的影响。 乐观并发使得读写进程不会相互阻塞，但是，这会导致一个潜在的问题，读进程可能会读取到老的数据。 2，悲观并发模式 这是默认的并发模式，在悲观并发模式下，SQL Server认为有大量的写操作发生，并且写操作会受到写操作的影响。也就是说

MySQL 就是其中之一，它经历了多个版本迭代。数据库锁是 MySQL 数据引擎的一部分，今天我们就一起来学习 MySQL 的数据库锁和它的优化。 MySQL 锁分类 当多个事务或者进程访问同一个资源的时候，为了保证数据的一致性，就需要用到锁机制。 从锁定资源的角度来看，MySQL 中的锁分为： 表级锁 行级锁 页面锁 表级锁：对整张表加锁。开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：对某行记录加锁。开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般。 在实际开发过程中，主要会使用到表级锁和行级锁两种。既然锁是针对资源的，那么这些资源就是数据，在 MySQL 提供插件式存储引擎对数据进行存储。 插件式存储引擎的好处是，开发人员可以根据需要选择适合的存储引擎。 在众多的存储引擎中，有两种引擎被比较多的使用，他们分别是： MyISAM 存储引擎，它不支持事务、表锁设计，支持全文索引，主要面向一些在线分析处理(OLAP)数据库应用。说白了主要就是查询数据，对数据的插入，更新操作比较少。 InnoDB 存储引擎，它支持事务，其设计目标主要面向在线事务处理(OLTP)的应用。 其特点是行锁设计、支持外键，并支持类似于 Oracle