数据库死锁

1. 为什么使用线程池 诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP 、 FTP 或 POP ）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。 构建服务器应用程序的一个简单模型是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上对于原型开发这种方法工作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程（ thread-per-request ）方法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。 除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或 “ 切换过度 ” 。为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。 线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建 的开销被分摊到了多个任务上。其好处是

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

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

转载： https://www.cnblogs.com/wezheng/p/8366029.html 目前，我们已经探讨了许多关于数据库锁的问题，锁能够有效地解决并发的问题，但这也带来了一个严重的缺点，那就是死锁。 死锁在操作系统中指的是两个或两个以上的进程在执行的过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或者系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 在操作系统中，死锁的处理是一个重要的话题，也已经有较为成熟的解决方法，如银行家算法等，在这边我们就不再阐述，只讨论数据库中的死锁。 数据库中常见的死锁原因与解决方案有： 1. 事务之间对资源访问顺序的交替 出现原因： 一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 解决方法： 这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源 2.

产生死锁的4个必要条件 互斥条件：在一段时间内某资源仅为一个线程所占有 不可剥夺条件：线程所获得的资源在未使用完毕之前，不能被其他线程强行夺走 请求和保持条件：线程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他线程占有 循环等待条件：存在一种线程资源的循环等待链，链中每一个线程已获得的资源同时被链中下一个线程所请求。 产生死锁的情况 多个锁的交叉（交叉锁） 交叉锁引起的线程会进入BLOCKED状态，CPU资源栈用不高，很容易借助工具发现 情景描述：线程A持有锁1，等待获取锁2；线程B持有锁2，等待获取锁1。 private final static Object MUTEX_READ = new Object(); private final static Object MUTEX_WRITE = new Object(); public void read(){ synchronized (MUTEX_READ) { synchronized (MUTEX_WRITE) { } } } public void write(){ synchronized (MUTEX_WRITE) { synchronized (MUTEX_READ) { } } } 内存不足 一问一答式的数据交换 服务器开启了某个端口，等待客户端的访问。客户端发送请求后等待服务器的响应

1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统

最近正式系统遇到了许多莫名奇妙的问题，定时器突然不跑了，业务流程跑不通。搞得人很崩溃，今天终于找到了原因，数据库中有好多条死锁。大概有100多条。（鬼知道发生了什么）然后赶紧杀了下。下面是sql，记录一下。（需要dba权限） -----查询锁表进程 select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao, v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid; ------查看锁表语句 SELECT b.sid oracleID, b.username 登录Oracle用户名, b.serial#, spid 操作系统ID, paddr, sql_text 正在执行的SQL, b.machine 计算机名 FROM v$process a, v$session b, v$sqlarea c WHERE a.addr = b.paddr AND b.sql_hash_value = c.hash_value -- and b.username = 'SMS' ---

oracle查看被锁的表和解锁 --以下几个为相关表 SELECT * FROM v$lock; SELECT * FROM v$sqlarea; SELECT * FROM v$session; SELECT * FROM v$process ; SELECT * FROM v$locked_object; SELECT * FROM all_objects; SELECT * FROM v$session_wait; --查看被锁的表 select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; --查看那个用户那个进程照成死锁 select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time; --查看连接的进程 SELECT sid, serial#, username, osuser FROM v$session; --3.查出锁定表的sid, serial#,os_user_name,

背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读

转载自何登成的技术博客：http://hedengcheng.com/?p=771 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。