数据库并发锁

1. 如何处理大量数据并发操作

处理大量数据并发操作可以采用如下几种方法:

1.使用缓存：使用程序直接保存到内存中。或者使用缓存框架: 用一个特定的类型值来保存，以区别空数据和未缓存的两种状态。

2.数据库优化：表结构优化;sql语句优化，语法优化和处理逻辑优化;分区;分表;索引优化;使用存储过程代替直接操作。

3.分离活跃数据:可以分为活跃用户和不活跃用户。

4.批量读取和延迟修改: 高并发情况可以将多个查询请求合并到一个。高并发且频繁修改的可以暂存缓存中。

5.读写分离: 数据库服务器配置多个，配置主从数据库。写用主数据库，读用从数据库。

6.分布式数据库: 将不同的表存放到不同的数据库中，然后再放到不同的服务器中。

7.NoSql和Hadoop: NoSql，not only SQL。没有关系型数据库那么多限制，比较灵活高效。Hadoop，将一个表中的数据分层多块，保存到多个节点（分布式）。每一块数据都有多个节点保存（集群）。集群可以并行处理相同的数据，还可以保证数据的完整性。

拓展资料:

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。

2. 数据库 什么是并发控制

简单来讲 并发控制是一种技术
在数据库中 由于可以同时有多个操作在进行（并行） 为了实现数据的一致性 采用了并发控制技术

3. mysql锁能控制并发吗

可以的，mysql中典型的是mvcc协议：

MVCC是为了实现数据库的并发控制而设计的一种协议。从直观理解上来看，要实现数据库的并发访问控制，最简单的做法就是加锁访问，即读的时候不能写（允许多个西线程同时读，即共享锁，S锁），写的时候不能读（一次最多只能有一个线程对同一份数据进行写操作，即排它锁，X锁）。这样的加锁访问，其实并不算是真正的并发，或者说它只能实现并发的读，因为它最终实现的是读写串行化，这样就大大降低了数据库的读写性能。加锁访问其实就是和MVCC相对的LBCC，即基于锁的并发控制（Lock-Based Concurrent Control），是四种隔离级别中级别最高的Serialize隔离级别。为了提出比LBCC更优越的并发性能方法，MVCC便应运而生。

4. 如何才能防止并发运行

锁述的概
一. 为什么要引入锁
多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:

丢失更新
A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统

脏读
A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致

不可重复读
A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数据时发现前后两次的值不一致

并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致

二 锁的分类
锁的类别有两种分法：
1. 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁
MS-SQL Server 使用以下资源锁模式。
锁模式 描述
共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。
更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。
排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。
意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。
架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。
大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。

5. 数据库并发问题对同一内容更改，mysql 表级行级锁都什么时候用

一般应用在设计的时候不需要考虑事务并发 .
只要控制好 , 增加,修改,删除在出错时候回滚数据就可以了 .

小型应用以及使用频繁的数据不要轻易加锁.
应用里面大量使用锁只会导致CPU高,且效率低.

如果出现某数据经常查询,且经常性修改,那么前期的数据库数据关联的设计肯定有问题.

6. 数据库高并发下乐观锁的原理

在高并发下，经常需要处理SELECT之后，在业务层处理逻辑，再执行UPDATE的情况。

若两个连接并发查询同一条数据，然后在执行一些逻辑判断或业务操作后，执行UPDATE，可能出现与预期不相符的结果。

在不使用悲观锁与复杂SQL的前提下，可以使用乐观锁处理该问题，同时兼顾性能。

场景模拟：

假设一张表两个字段，一个id，一个use_count。
表里存了100个id，每个id对应自己的use_count。

当id每使用一次，use_count要加1。当use_count大于1000时，这个id就不能在被使用了（换句话说 无法从数据库中查出）。

在高并发情况下，会遇到一种问题：假设数据表中有一条记录为：id=123456, use_count=999
A与B两个连接并发查询这个id=123456，都执行下列SQL:

SELECT*FROMtableWHEREid=123456anse_count<1000;

A先执行，得到id=123456的use_count是999，之后在程序里做了一些逻辑判断或业务操作后执行SQL：

UPDATEtableSETuse_count+1WHEREid=123456;

在A做判断且没有update之前，B也执行了查询SQL，发现use_count是999，之后它也会执行SQL：

UPDATEtableSETuse_count+1WHEREid=123456;

但是，事实上B不应该取得这个id，因为A已经是第1000个使用者。

处理步骤如下：

1、添加第3个字段version，int类型，default值为0。version值每次update时作加1处理。

'0'NOTNULLAFTERuse_count;

2、SELECT时同时获取version值（例如为3）。

SELECTuse_count,versionFROMtableWHEREid=123456ANDuse_count<1000;

3、UPDATE时检查version值是否为第2步获取到的值。

UPDATEtableSETversion=4,use_count=use_count+1WHEREid=123456ANDversion=3;

如果UPDATE的记录数为1，则表示成功。
如果UPDATE的记录数为0，则表示已经被其他连接UPDATE过了，需作异常处理。

参考地址：http://latrell.me/post-358.html

7. 数据库的并发操作可能带来哪些问题 丢失更新 死锁 违反唯一性约束

数据库中常见的并发操作所带来的一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。
丢失修改
下面先来看一个例子，说明并发操作带来的数据的不一致性问题。
考虑飞机订票系统中的一个活动序列:
甲售票点（甲事务）读出某航班的机票余额A,设A=16.
乙售票点（乙事务）读出同一航班的机票余额A,也为16.
甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.
乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.
结果明明卖出两张机票，数据库中机票余额只减少1。
归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（2.1.4数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是：
不可重复读
不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况：
事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200，与第一次读取值不一致。
事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神密地消失了。
事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。（这也叫做幻影读）
读"脏"数据
读"脏"数据是指事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤消，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为"脏"数据，即不正确的数据。
产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其它事务的干扰，从而避免造成数据的不一致性。
并发一致性问题的解决办法
封锁（Locking）
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表

8. 举例说明什么是分布式数据库系统并发控制中的全局死锁

db2 是对某表某一条记录操作的时候,他会对整个表进行表锁定,如果设置的事务级别是可重复的读,那么另外一个人的同步操作就会被回滚,不过可以通过sql语句指定锁定级别,sqlserver默认是对行数据进行锁定,你如果要看这个问题,你可以先研究一下数据库的锁定方式和锁定级别,死锁是一定存在的,特别是在并发操作很多的情况,这个和你数据库的设计有关系,关键是捕获到死锁后怎么样对死锁进行释放

9. DB2如何解决并发锁表问题

先定位一下是哪个程序句柄导致的死锁。
方法一、查看db2diag.log文件
找到DeadLock or Lock timeout 死锁或锁超时信息
db2 force application(句柄ID)
直接结束进程即可。
方法二、DB2快照信息
1、看一下DB2快照信息
db2 get snapshot for locks on sample
可以得到类似信息：
数据库锁定快照
数据库名称 = SAMPLE
数据库路径 = D:\IBM\DB2\NODE0000\SQL00001\
输入数据库别名 = SAMPLE
挂起的锁定 = 8
当前已连接的应用程序 = 2
当前正等待锁定的代理程序数 = 1
应用程序句柄 = 54
应用程序标识 = *LOCAL.DB2.140304192925
序号 = 00001
应用程序名 = db2bp.exe CONNECT
授权标识 = DB2ADMIN
应用程序状态 = 锁定等待
应用程序代码页 = 1208
挂起的锁定 = 4
总计等待时间（毫秒） = 247867
锁定列表
锁定名称 = 0x5359534C564C3031DDECEF2841
锁定属性 = 0x00000000
发行版标志 = 0x40000000
锁定计数 = 1
挂起计数 = 0
锁定对象名 = 2312
对象类型 = 行
表空间名 = IBMDB2SAMPLEREL
表模式 = DB2ADMIN
表名 = TEST
方式 = IX
查看锁定的详细信息：db2 get snapshot for locks for application agentid 1728
----（1728是句柄ID）
3、观察命令db2 list applications的输出
查看应用程序的状态是否有锁定等待(Lock-wait)状态出现。
执行命令 list applications for db sample show detail;
4、db2 force application(句柄ID)
直接结束进程即可。

10. sql server 2008 并发 锁定行的难题~

1、如果是为了提高查询效率的话就没必要这么做，如果数据量大了导致查询慢的话可以采用表分区或者建立索引。
2、如果是业务上有这种要求的话，你可以采用ROW_NUMBER函数根据主键列排号，不同的线程使用不同的号段，分别插入数据库。这样可以避免加锁操作，从而避免死锁。
3、尽量去使用INSERT INTO 表(字段) SELECT 字段 FROM 表语句。
4、所有线程执行完毕之后使用TRUNCATE TABLE去清理数据比较好。