数据库 对某条记录实现锁机制

recordset的open语句后边的参数就可以控制

RSOPEN SQL,CONN,A,B

A:

ADOPENFORWARDONLY(=0)

只读,且当前数据记录只能向下移动

ADOPENKEYSET(=1)

只读,当前数据记录可自由移动

ADOPENDYNAMIC(=2)

可读写,当前数据记录可自由移动

ADOPENSTATIC(=3)

可读写,当前数据记录可自由移动,可看到新增记录

B:

ADLOCKREADONLY(=1)

缺省锁定类型，记录集是只读的，不能修改记录

ADLOCKPESSIMISTIC(=2)

悲观锁定，当修改记录时，数据提供者将尝试锁定记录以确保成功地编辑记录。只要编辑一开始，则立即锁住记录。

ADLOCKOPTIMISTIC(=3)

乐观锁定 ，直到用Update方法提交更新记录时才锁定记录。

ADLOCKBATCHOPTIMISTIC(=4)

批量乐观锁定，允许修改多个记录，只有调用UpdateBatch方法后才锁定记录。

当不需要改动任何记录时，应该使用只读的记录集，这样提供者不用做任何检测。

对于一般的使用，乐观的锁定可能是最好的选择，因为记录只被锁定一小段时间，

数据在这段时间被更新。这减少了资源的使用。

1、数据库锁表的意思：因为在数据库里，同一个数据可能有多个人来读取或更改，为了防止我更改的时候别人也同时更改，这是一般要锁住表不让别人改。

2、举个简单例子：在更新数据库记录的过程中，我是不希望别人也来更新我的这些记录的，像库存，做出库的时候，原数量100，我出了20，我就需要把数量更新到80；

在更新的过程中，别人又做了30的出库，如果在我更新的时候，别人先把库存更新到70，然后我又更新80，那数量就错误了。所以我更新的时候，我就需要锁定这条记录。这是数据行锁，排他锁。

扩展资料：

数据库锁表的必要条件：

1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。

3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。

4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

1 引言—数据库锁的基本概念

为了确保并发用户在存取同一数据库对象时的正确性（即无丢失修改、可重复读、不读“脏”数据），数据库中引入了锁机制。基本的锁类型有两种：排它锁（Exclusive locks记为X锁）和共享锁（Share locks记为S锁）。

排它锁：若事务T对数据D加X锁，则其它任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加排它锁，所以排它锁又称为写锁。

共享锁：若事务T对数据D加S锁，则其它事务只能对D加S锁，而不能加X锁，直至T释放D上的S锁；一般要求在读取数据前要向该数据加共享锁，所以共享锁又称为读锁。

2 Oracle 多粒度封锁机制介绍

根据保护对象的不同，Oracle数据库锁可以分为以下几大类：

(1) DML lock（data locks，数据锁）：用于保护数据的完整性；

(2) DDL lock（dictionary locks，字典锁）：用于保护数据库对象的结构（例如表、视图、索引的结构定义）；

(3) internal locks 和l a t c h es（内部锁与闩）：保护内部数据库结构；

(4) distributed locks（分布式锁）：用于OPS（并行服务器）中；

(5) PCM locks（并行高速缓存管理锁）：用于OPS（并行服务器）中。

本文主要讨论DML（也可称为data locks，数据锁）锁。从封锁粒度（封锁对象的大小）的角度看，Oracle DML锁共有两个层次，即行级锁和表级锁。

21 Oracle的TX锁（行级锁、事务锁）

许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行，其实不然。TX的本义是Transaction（事务），当一个事务第一次执行数据更改（Insert、Update、Delete）或使用SELECT… FOR UPDATE语句进行查询时，它即获得一个TX（事务）锁，直至该事务结束（执行COMMIT或ROLLBACK *** 作）时，该锁才被释放。所以，一个TX锁，可以对应多个被该事务锁定的数据行。

在Oracle的每行数据上，都有一个标志位来表示该行数据是否被锁定。Oracle不象其它一些DBMS（数据库管理系统）那样，建立一个链表来维护每一行被加锁的数据，这样就大大减小了行级锁的维护开销，也在很大程度上避免了其它数据库系统使用行级封锁时经常发生的锁数量不够的情况。数据行上的锁标志一旦被置位，就表明该行数据被加X锁，Oracle在数据行上没有S锁。

22 TM锁（表级锁）

221 意向锁的引出

表是由行组成的，当我们向某个表加锁时，一方面需要检查该锁的申请是否与原有的表级锁相容；另一方面，还要检查该锁是否与表中的每一行上的锁相容。比如一个事务要在一个表上加S锁，如果表中的一行已被另外的事务加了X锁，那么该锁的申请也应被阻塞。如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。为了解决这个问题，可以在表级引入新的锁类型来表示其所属行的加锁情况，这就引出了“意向锁”的概念。

意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。如：对表中的任一行加锁时，必须先对它所在的表加意向锁，然后再对该行加锁。这样一来，事务对表加锁时，就不再需要检查表中每行记录的锁标志位了，系统效率得以大大提高。

222 意向锁的类型

由两种基本的锁类型（S锁、X锁），可以自然地派生出两种意向锁：

意向共享锁（Intent Share Lock，简称IS锁）：如果要对一个数据库对象加S锁，首先要对其上级结点加IS锁，表示它的后裔结点拟（意向）加S锁；

意向排它锁（Intent Exclusive Lock，简称IX锁）：如果要对一个数据库对象加X锁，首先要对其上级结点加IX锁，表示它的后裔结点拟（意向）加X锁。

另外，基本的锁类型（S、X）与意向锁类型（IS、IX）之间还可以组合出新的锁类型，理论上可以组合出4种，即：S+IS，S+IX，X+IS，X+IX，但稍加分析不难看出，实际上只有S+IX有新的意义，其它三种组合都没有使锁的强度得到提高（即：S+IS=S，X+IS=X，X+IX=X，这里的“=”指锁的强度相同）。所谓锁的强度是指对其它锁的排斥程度。

这样我们又可以引入一种新的锁的类型

共享意向排它锁（Shared Intent Exclusive Lock,简称SIX锁） ：如果对一个数据库对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。例如：事务对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加S锁），同时会更新个别行（所以要对该表加IX锁）。

这样数据库对象上所加的锁类型就可能有5种：即S、X、IS、IX、SIX。

具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁，必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行；释放封锁时则应按自下而上的次序进行；具有意向锁的多粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。

前段时间跟踪 MyBatis 源码，分析 MyBatis 的分页查询结果后，发现传入的 IPage 参数结果已经包含了查询数据了，以为分页查询语句的关键在于第一个入参必须是 IPage ，而不需要返回值了呢。

昨天发现不是这么回事儿，本文再回顾一下 MyBatis 分页插件的用法及三个发现：

本文讲解答上面三个问题。

第一步 ，设置分页查询插件。

第二步 ，编写分页查询 DAO 方法：

该方法执行完成后，查询数据会存储到 iPage 参数中，可以直接获取方法返回值。值得注意的是，这个方法必须有返回值。

我最初以为，查询结果都存储到参数中了，是不是方法定义中可以不用返回值了。昨天编码时就随手写成这样了：

结果，执行报 了 SQL 异常：

纳闷了半天，这分页查询怎么就变成了单条查询了呢？对比旧项目代码，还原分页查询方法，正常了。

结论 ：MyBatisPlus 分页方法返回值必须是 IPage ，不能为 void 。

以往页面的分页查询，每页数据都很少，没有发现这个问题。

这次实现的是一个批处理任务，一次处理的数据要尽量大。 iPage 分页参数 size 初始设置为 1000，发现日志输出的记录数总是 500 条 ,分页参数失效了，为何呢？

使用客户端连接数据库查询，一次能取 1000 条，而 MyBatisPlus 分页查询，这个 500 条是谁控制的呢？能否修改呢？

答案是 ： PaginationInterceptor 限制了单页条数 500，如果需要，可以这样修改：

业务要求某个任务设计成多机、并行任务，且要保证数据一致。Quartz 框架的分布式任务只能保证任务被一个节点执行，不符合需求，Spring Task 倒是可以实现。

所以问题就变成分布式锁的设计了，参考 Quartz 的集群方案中的锁机制，实现基于数据库行锁的锁。

没测试基于行锁的分布式锁之前，我以为某个事务执行 select for update 之后，其他事务再对相同记录执行该 *** 作的话，应该会报异常，导致锁获取失败。

测试发现，某条记录被锁定之后，交互流程大概是这样的：

结论 ：数据库记录的行锁是排他的，其他事务会阻塞等待。

辛丑年腊月二十八，上述就是今年最后一个工作日的总结。

收拾收拾，准备迎接农历新年！

方法：

1。

改表法。可能是你的帐号不允许从远程登陆，只能在

localhost

。这个时候只要在localhost的那台电脑，登入mysql后，更改

"mysql"

数据库里的

"user"

表里的

"host"

项，从"localhost"改称"%"

mysql

-u

root

-pvmwaremysql>use

mysql;mysql>update

user

set

host

=

'%'

where

user

=

'root';mysql>select

host,

user

from

user;

2

授权法

。例如，你想myuser使用mypassword从任何主机连接到mysql服务器的话。

不需要，就算确实用户同时执行，数据库的 *** 作机制是有队列的，所以不存在并发情况。

锁基本用不到，我反正开发了5年了没用到过。

你要了解死锁发生的情况，一般是用事务的时候可能会碰到死锁，你申请了A资源，锁住了A然后申请B资源，其他人申请了B资源，然后申请A，这样就互不相让，导致A,B资源都不可访问了，不过其他数据我不知道，SQLSERVER发生这种死锁不是一直锁死的，过几分钟就会发现这个死锁，把锁释放掉，2个事务都失败。

以上就是关于数据库 对某条记录实现锁机制全部的内容，包括:数据库 对某条记录实现锁机制、数据库锁表是什么意思、oracle--对锁机制的理解-等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！