精华内容
下载资源
问答
  • 数据库安全机制.pdf

    2020-01-26 19:55:08
    1.1数据库安全机制 数据库安全机制是用于实现数据库的各种安全策略的功能集合 正是由这些安全机制来 实现安全模型进而实现保护数据库系统安全的目标 数据库系统的安全机制如图示 授权机制 约束机制 审计 身份验证 ...
  • 数据库机制

    万次阅读 多人点赞 2016-08-15 12:38:50
    看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程。T3,T4以此类推。下面以SQL Server...

    1 前言

    数据库大并发操作要考虑死锁和锁的性能问题。看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程。T3,T4以此类推。下面以SQL Server(2005)为例。

    2 锁的种类

    1. 共享锁(Shared lock)。
      例1:
      ----------------------------------------
      T1:    select * from table (请想象它需要执行1个小时之久,后面的sql语句请都这么想象)
      T2:    update table set column1='hello'
      
      过程:
      
      T1运行 (加共享锁)
      T2运行
      If T1 还没执行完
          T2等......
      else
          锁被释放
          T2执行
      endif
      
      T2之所以要等,是因为T2在执行update前,试图对table表加一个排他锁,
      而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1
      执行完,释放了共享锁,才能加上排他锁,然后才能开始执行update语句。
      
      例2:
      ----------------------------------------
      T1:    select * from table
      T2:    select * from table
      
      这里T2不用等待T1执行完,而是可以马上执行。
      
      分析:
      T1运行,则table被加锁,比如叫lockA
      T2运行,再对table加一个共享锁,比如叫lockB。
      
      两个锁是可以同时存在于同一资源上的(比如同一个表上)。这被称为共
      享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源,但阻
      止其它session update
      
      例3:
      ----------------------------------------
      T1:    select * from table
      T2:    select * from table
      T3:    update table set column1='hello'
      
      这次,T2不用等T1运行完就能运行,T3却要等T1和T2都运行完才能运行。
      因为T3必须等T1和T2的共享锁全部释放才能进行加排他锁然后执行update
      操作。
      
      例4:(死锁的发生)
      ----------------------------------------
      T1:
      begin tran
      select * from table (holdlock) (holdlock意思是加共享锁,直到事物结束才释放)
      update table set column1='hello'
      
      T2:
      begin tran
      select * from table(holdlock)
      update table set column1='world'
      
      假设T1和T2同时达到select,T1对table加共享锁,T2也对加共享锁,当
      T1的select执行完,准备执行update时,根据锁机制,T1的共享锁需要升
      级到排他锁才能执行接下来的update.在升级排他锁前,必须等table上的
      其它共享锁释放,但因为holdlock这样的共享锁只有等事务结束后才释放,
      所以因为T2的共享锁不释放而导致T1等(等T2释放共享锁,自己好升级成排
      他锁),同理,也因为T1的共享锁不释放而导致T2等。死锁产生了。
      
      例5:
      ----------------------------------------
      T1:
      begin tran
      update table set column1='hello' where id=10
      
      T2:
      begin tran
      update table set column1='world' where id=20
      
      这种语句虽然最为常见,很多人觉得它有机会产生死锁,但实际上要看情
      况,如果id是主键上面有索引,那么T1会一下子找到该条记录(id=10的记
      录),然后对该条记录加排他锁,T2,同样,一下子通过索引定位到记录,
      然后对id=20的记录加排他锁,这样T1和T2各更新各的,互不影响。T2也不
      需要等。
      
      但如果id是普通的一列,没有索引。那么当T1对id=10这一行加排他锁后,
      T2为了找到id=20,需要对全表扫描,那么就会预先对表加上共享锁或更新
      锁或排他锁(依赖于数据库执行策略和方式,比如第一次执行和第二次执行
      数据库执行策略就会不同)。但因为T1已经为一条记录加了排他锁,导致
      T2的全表扫描进行不下去,就导致T2等待。
      
      死锁怎么解决呢?一种办法是,如下:
      例6:
      ----------------------------------------
      T1:
      begin tran
      select * from table(xlock) (xlock意思是直接对表加排他锁)
      update table set column1='hello'
      
      T2:
      begin tran
      select * from table(xlock)
      update table set column1='world'
      
      这样,当T1的select 执行时,直接对表加上了排他锁,T2在执行select时,就需要等T1事物完全执行完才能执行。排除了死锁发生。
      但当第三个user过来想执行一个查询语句时,也因为排他锁的存在而不得不等待,第四个、第五个user也会因此而等待。在大并发
      情况下,让大家等待显得性能就太友好了,所以,这里引入了更新锁。
      
    2. 更新锁(Update lock)
      为解决死锁,引入更新锁。
      
      例7:
      ----------------------------------------
      T1:
      begin tran
      select * from table(updlock) (加更新锁)
      update table set column1='hello'
      T2:
      begin tran
      select * from table(updlock)
      update table set column1='world'
      
      更新锁的意思是:“我现在只想读,你们别人也可以读,但我将来可能会做更新操作,我已经获取了从共享锁(用来读)到排他锁
      (用来更新)的资格”。一个事物只能有一个更新锁获此资格。
      
      T1执行select,加更新锁。
      T2运行,准备加更新锁,但发现已经有一个更新锁在那儿了,只好等。
      
      当后来有user3、user4...需要查询table表中的数据时,并不会因为T1的select在执行就被阻塞,照样能查询,相比起例6,这提高
      了效率。
      
      例8:
      ----------------------------------------
      T1:    select * from table(updlock)    (加更新锁)
      T2:    select * from table(updlock)    (等待,直到T1释放更新锁,因为同一时间不能在同一资源上有两个更新锁)
      T3:    select * from table (加共享锁,但不用等updlock释放,就可以读)
      
      这个例子是说明:共享锁和更新锁可以同时在同一个资源上。这被称为共享锁和更新锁是兼容的。
      
      例9:
      ----------------------------------------
      T1:
      begin
      select * from table(updlock)      (加更新锁)
      update table set column1='hello'  (重点:这里T1做update时,不需要等T2释放什么,而是直接把更新锁升级为排他锁,然后执行update)
      T2:
      begin
      select * from table               (T1加的更新锁不影响T2读取)
      update table set column1='world'  (T2的update需要等T1的update做完才能执行)
      
      我们以这个例子来加深更新锁的理解,
      
      第一种情况:T1先达,T2紧接到达;在这种情况中,T1先对表加更新锁,T2对表加共享锁,假设T2的select先执行完,准备执行update,
      发现已有更新锁存在,T2等。T1执行这时才执行完select,准备执行update,更新锁升级为排他锁,然后执行update,执行完成,事务
      结束,释放锁,T2才轮到执行update。
      
      第二种情况:T2先达,T1紧接达;在这种情况,T2先对表加共享锁,T1达后,T1对表加更新锁,假设T2 select先结束,准备
      update,发现已有更新锁,则等待,后面步骤就跟第一种情况一样了。
      
      这个例子是说明:排他锁与更新锁是不兼容的,它们不能同时加在同一子资源上。
      
      
    3. 排他锁(独占锁,Exclusive Locks)
      这个简单,即其它事务既不能读,又不能改排他锁锁定的资源。
      例10
      T1:    update table set column1='hello' where id<1000
      T2:    update table set column1='world' where id>1000
      
      假设T1先达,T2随后至,这个过程中T1会对id<1000的记录施加排他锁.但不会阻塞T2的update。
      
      例11 (假设id都是自增长且连续的)
      T1:    update table set column1='hello' where id<1000
      T2:    update table set column1='world' where id>900
      
      如同例10,T1先达,T2立刻也到,T1加的排他锁会阻塞T2的update.
      
    4. 意向锁(Intent Locks)
      意向锁就是说在屋(比如代表一个表)门口设置一个标识,说明屋子里有人(比如代表某些记录)被锁住了。另一个人想知道屋子
      里是否有人被锁,不用进屋子里一个一个的去查,直接看门口标识就行了。
      
      当一个表中的某一行被加上排他锁后,该表就不能再被加表锁。数据库程序如何知道该表不能被加表锁?一种方式是逐条的判断该
      表的每一条记录是否已经有排他锁,另一种方式是直接在表这一层级检查表本身是否有意向锁,不需要逐条判断。显然后者效率高。
      
      例12:
      ----------------------------------------
      T1:    begin tran
             select * from table (xlock) where id=10  --意思是对id=10这一行强加排他锁
      T2:    begin tran
             select * from table (tablock)     --意思是要加表级锁
             
      假设T1先执行,T2后执行,T2执行时,欲加表锁,为判断是否可以加表锁,数据库系统要逐条判断table表每行记录是否已有排他锁,
      如果发现其中一行已经有排他锁了,就不允许再加表锁了。只是这样逐条判断效率太低了。
      
      实际上,数据库系统不是这样工作的。当T1的select执行时,系统对表table的id=10的这一行加了排他锁,还同时悄悄的对整个表
      加了意向排他锁(IX),当T2执行表锁时,只需要看到这个表已经有意向排他锁存在,就直接等待,而不需要逐条检查资源了。
      
      例13:
      ----------------------------------------
      T1:    begin tran
             update table set column1='hello' where id=1
      T2:    begin tran
             update table set column1='world' where id=1
      
      这个例子和上面的例子实际效果相同,T1执行,系统对table同时对行家排他锁、对页加意向排他锁、对表加意向排他锁。
      
    5. 计划锁(Schema Locks)
      例14:
      ----------------------------------------
      alter table .... (加schema locks,称之为Schema modification (Sch-M) locks
      
      DDL语句都会加Sch-M锁
      该锁不允许任何其它session连接该表。连都连不了这个表了,当然更不用说想对该表执行什么sql语句了。
      
      例15:
      ----------------------------------------
      用jdbc向数据库发送了一条新的sql语句,数据库要先对之进行编译,在编译期间,也会加锁,称之为:Schema stability (Sch-S) locks
      
      select * from tableA
      
      编译这条语句过程中,其它session可以对表tableA做任何操作(update,delete,加排他锁等等),但不能做DDL(比如alter table)操作。
      
    6. Bulk Update Locks 主要在批量导数据时用(比如用类似于oracle中的imp/exp的bcp命令)。不难理解,程序员往往也不需要关心,不赘述了。

    3 何时加锁?

    如何加锁,何时加锁,加什么锁,你可以通过hint手工强行指定,但大多是数据库系统自动决定的。这就是为什么我们可以不懂锁也可
    以高高兴兴的写SQL。
    
    例15:
    ----------------------------------------
    T1:    begin tran
           update table set column1='hello' where id=1
    T2:    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED  -- 事物隔离级别为允许脏读
           go
           select * from table where id=1
    这里,T2的select可以查出结果。如果事物隔离级别不设为脏读,则T2会等T1事物执行完才能读出结果。
    
    数据库如何自动加锁的?
    
    1) T1执行,数据库自动加排他锁
    2) T2执行,数据库发现事物隔离级别允许脏读,便不加共享锁。不加共享锁,则不会与已有的排他锁冲突,所以可以脏读。
    
    例16:
    ----------------------------------------
    T1:    begin tran
           update table set column1='hello' where id=1
    T2:    select * from table where id=1 --为指定隔离级别,则使用系统默认隔离级别,它不允许脏读
    
    如果事物级别不设为脏读,则:
    1) T1执行,数据库自动加排他锁
    2) T2执行,数据库发现事物隔离级别不允许脏读,便准备为此次select过程加共享锁,但发现加不上,因为已经有排他锁了,所以就
       等啊等。直到T1执行完,释放了排他锁,T2才加上了共享锁,然后开始读....
    

    4 锁的粒度

    锁的粒度就是指锁的生效范围,就是说是行锁,还是页锁,还是整表锁. 锁的粒度同样既可以由数据库自动管理,也可以通过手工指定hint来管理。

    例17:
    ----------------------------------------
    T1:    select * from table (paglock)
    T2:    update table set column1='hello' where id>10
    
    T1执行时,会先对第一页加锁,读完第一页后,释放锁,再对第二页加锁,依此类推。假设前10行记录恰好是一页(当然,一般不可能
    一页只有10行记录),那么T1执行到第一页查询时,并不会阻塞T2的更新。
    
    例18:
    ----------------------------------------
    T1:    select * from table (rowlock)
    T2:    update table set column1='hello' where id=10
    
    T1执行时,对每行加共享锁,读取,然后释放,再对下一行加锁;T2执行时,会对id=10的那一行试图加锁,只要该行没有被T1加上行锁,
    T2就可以顺利执行update操作。
    
    例19:
    ----------------------------------------
    T1:    select * from table (tablock)
    T2:    update table set column1='hello' where id = 10
    
    T1执行,对整个表加共享锁. T1必须完全查询完,T2才可以允许加锁,并开始更新。
    
    以上3例是手工指定锁的粒度,也可以通过设定事物隔离级别,让数据库自动设置锁的粒度。不同的事物隔离级别,数据库会有不同的
    加锁策略(比如加什么类型的锁,加什么粒度的锁)。具体请查联机手册。
    

    5 锁与事物隔离级别的优先级

    手工指定的锁优先,
    例20:
    ----------------------------------------
    T1:    GO
           SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
           GO
           BEGIN TRANSACTION
           SELECT * FROM table (NOLOCK)
           GO
    T2:    update table set column1='hello' where id=10
    
    T1是事物隔离级别为最高级,串行锁,数据库系统本应对后面的select语句自动加表级锁,但因为手工指定了NOLOCK,所以该select
    语句不会加任何锁,所以T2也就不会有任何阻塞。
    

    6 数据库的其它重要Hint以及它们的区别

    1) holdlock 对表加共享锁,且事物不完成,共享锁不释放。
    2) tablock  对表加共享锁,只要statement不完成,共享锁不释放。
       与holdlock区别,见下例:
       例21
       ----------------------------------------
       T1:
       begin tran
       select * from table (tablock)
       T2:
       begin tran
       update table set column1='hello' where id = 10
    
       T1执行完select,就会释放共享锁,然后T2就可以执行update. 此之谓tablock. 下面我们看holdlock
       例22
       ----------------------------------------
       T1:
       begin tran
       select * from table (holdlock)
       T2:
       begin tran
       update table set column1='hello' where id = 10
       
       T1执行完select,共享锁仍然不会释放,仍然会被hold(持有),T2也因此必须等待而不能update. 当T1最后执行了commit或
       rollback说明这一个事物结束了,T2才取得执行权。
      
    3) TABLOCKX 对表加排他锁
      
       例23:
       ----------------------------------------
       T1:    select * from table(tablockx) (强行加排他锁)
       其它session就无法对这个表进行读和更新了,除非T1执行完了,就会自动释放排他锁。
       例24:
       ----------------------------------------
       T1:    begin tran
              select * from table(tablockx)
       这次,单单select执行完还不行,必须整个事物完成(执行了commit或rollback后)才会释放排他锁。
      
    4) xlock 加排他锁
       那它跟tablockx有何区别呢?
    
       它可以这样用,
       例25:
       ----------------------------------------
       select * from table(xlock paglock) 对page加排他锁
       而TABLELOCX不能这么用。
    
       xlock还可这么用:select * from table(xlock tablock) 效果等同于select * from table(tablockx)
    

    7 锁的超时等待

    例26

    SET LOCK_TIMEOUT 4000 用来设置锁等待时间,单位是毫秒,4000意味着等待
    4秒可以用select @@LOCK_TIMEOUT查看当前session的锁超时设置。-1 意味着
    永远等待。
    
    T1: begin tran
        udpate table set column1='hello' where id = 10
    T2: set lock_timeout 4000
        select * from table wehre id = 10
    

    T2执行时,会等待T1释放排他锁,等了4秒钟,如果T1还没有释放排他锁,T2就会抛出异常: Lock request time out period exceeded.

    8 附:各种锁的兼容关系表

    | Requested mode                     | IS  | S   | U   | IX  | SIX | X  |
    | Intent shared (IS)                 | Yes | Yes | Yes | Yes | Yes | No |
    | Shared (S)                         | Yes | Yes | Yes | No  | No  | No |
    | Update (U)                         | Yes | Yes | No  | No  | No  | No |
    | Intent exclusive (IX)              | Yes | No  | No  | Yes | No  | No |
    | Shared with intent exclusive (SIX) | Yes | No  | No  | No  | No  | No |
    | Exclusive (X)                      | No  | No  | No  | No  | No  | No |
    

    9 如何提高并发效率

    1. 悲观锁:利用数据库本身的锁机制实现。通过上面对数据库锁的了解,可以根据具体业务情况综合使用事务隔离级别与合理的手工指定锁的方式比如降低锁的粒度等减少并发等待。
    2. 乐观锁:利用程序处理并发。原理都比较好理解,基本一看即懂。方式大概有以下3种
      1. 对记录加版本号.
      2. 对记录加时间戳.
      3. 对将要更新的数据进行提前读取、事后对比。

    不论是数据库系统本身的锁机制,还是乐观锁这种业务数据级别上的锁机制,本质上都是对状态位的读、写、判断。

    展开全文
  • MySQL数据库机制

    千次阅读 2018-11-27 11:22:22
    锁是计算机协调多个进程或纯线程并发访问某一资源的机制。在数据库中,除传统的计算资源(CPU、RAM、I/O)的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所在有数据库必须...

    锁是计算机协调多个进程或纯线程并发访问某一资源的机制。在数据库中,除传统的计算资源(CPU、RAM、I/O)的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所在有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。在MySQL数据库中支持多种不同粒度的锁来兼顾数据库并发与一致性问题。本文主要描述MySQL锁工作机制及其锁类型,粒度等。

    一、MySQL数据库锁管理机制

    SQL层实现的锁机制
       Meta-data元数据锁:在table cache缓存里实现的,为DDL(Data Definition Language)提供隔离操作。一种特别的meta-data元数据类型,叫Name Lock。
       表级table-level数据锁
       全局读锁—FLUSH TABLES WITH READ LOCK

    引擎层实现的锁机制
       存储引擎特有机制—row locks行锁,page locks页锁,table locks表级,版本控制
    在这里插入图片描述

    二、锁执行流程

    计算语句使用到的所有表
    在每个表:打开open表—从table cache缓存里得到TABLE对象,并在此表加上meta-data元数据锁
    等待全局读锁后改变数据
    在每个表:锁lock表—在表加上table-level数据锁
    执行语句:调用:handler::write_row()/read_rnd()/read_index()等;隐式地调用引擎级engine-level锁机制
    在每个表:释放表的数据锁
    在每个表:释放表的DDL锁并把表放回table?cache缓存里
    DDL语句也是一样,没有典型的执行计划
    在这里插入图片描述

    三、锁粒度

    共享锁(S):允许一个事务去读一行
    排他锁(X):允许一个事务更新或删除一行
    事务A锁住了表中的一行,让这一行只能读,不能写。之后,事务B申请整个表的写锁。如果事务B申请成功,那么理论上它就能修改表中的任意一行,这与A持有的行锁是冲突的。数据库需要避免这种冲突,就是说要让B的申请被阻塞,直到A释放了行锁。数据库要怎么判断这个冲突呢?
    普通认为两步:
       step1:判断表是否已被其他事务用表锁锁表。
       step2:判断表中的每一行是否已被行锁锁住。但是这样的方法效率很低,因为要遍历整个表。
    所以解决方案是:意向锁。

    InnoDB支持多粒度锁定,这种锁定允许在行级上的锁和表级上的锁同时存在。因此InnoDB还有两种内部使用的意向锁(Intention Locks),这两种意向锁都是表级锁。用于解决表级锁和行级锁之间的冲突
       意向共享锁(IS):事务打算给数据行加行共享锁,事务在给一个数据行加共享锁前必须先取得该表的IS锁。
       意向排他锁(IX):事务打算给数据行加行排他锁,事务在给一个数据行加排他锁前必须先取得该表的IX锁。

    间隙锁
    当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据记录的索引项加锁;对于键值在条件范围内但不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁(NEXT-KEY)锁。

    因为Query执行过程中通过范围查找的话,他会锁定整个范围内所有的索引键值,即使这个键值并不存在。
    间隙锁有一个比较致命的弱点,就是当锁定一个范围键值之后,即使某些不存在的键值也会被无辜的锁定,而造成在锁定的时候无法插入锁定值范围内的任何数据,在某些场景下这可能会针对性造成很大的危害。
    在这里插入图片描述

    四、InnoDB行级锁

    在这里插入图片描述

    展开全文
  • 数据库安全机制 精品文档 精品文档 收集于网络如有侵权请联系管理员删除 收集于网络如有侵权请联系管理员删除 精品...数据库系统的安全机制如图示 触发器 触发器 数据库服务器 (RDBMS) 授权机制 约束机制 审计 视图
  • 数据库管理系统作为信息系统的核心部件,在信息化时代充当的角色是其它任何软件不能替代的。当前数据库应用的一个普遍要求是数据库管理系统能够在一些数据库相关事件发生时触发预先定义的操作,实现信息管理的...
  • 数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制,所以MySQL自然也不能例外。MySQL数据库由于其...
  • 数据库管理系统作为信息系统的核心部件,在信息化时代充当的角色是其它任何软件不能替代的。当前数据库应用的一个普遍要求是数据库管理系统能够在一些数据库相关事件发生时触发预先定义的操作,实现信息管理的自动...
  • 数据库安全机制是用于实现数据库的各种安全策略的功能集合 正是由这些安全机制来 实现安全模型进而实现保护数据库系统安全的目标 数据库系统的安全机制如图示 1.13.1用户标识与鉴别 用户标识是指用户向系统出示...
  • 数据库安全机制

    千次阅读 2018-06-10 00:10:23
    数据库作为重要的数据文件库,其安全性是非常重要的。(此处的安全性是指操作上的安全性,DCL模块,而不是广义上的网络安全,服务器安全等安全性)通常是通过DCL(数据库控制语言)来实现对数据库的权限的管理。...

    数据库作为重要的数据文件库,其安全性是非常重要的。(此处的安全性是指操作上的安全性,DCL模块,而不是广义上的网络安全,服务器安全等安全性)通常是通过DCL(数据库控制语言)来实现对数据库的权限的管理。

    AccessRule ::=(S,O,T,P)  (用户,对象,权力,谓词条件)

    eg: 对一个员工数据库

    Employee(P#,Pname,Page,Psex,Psalary,D#,HEAD)

    员工管理人员应该享有全部权力,收发信息人员应能查询员工名即部门,等等

    其实现方式可使用储存矩阵或视图方式,储存矩阵的格式行为DB中的对象,第一列为用户ID,表内的值为权限(r,d,i,u)

    视图方式为创建某一视图,将该视图的访问权分配给指定用户,eg:

    Create Empv1 as select * from Employee

    数据库DB,通常由DBA来创建并同时定义一系列的用户,其次会在用户中定义一个账户级别的用户A(列如员工数据管理库的管理员),由A来定义一系列的基本表和视图并将权力分配给其他用户,常用权力分3级:

    Level 1 : select 读                 Level 2 : modify  更新            1、2级为关系级别

    Level 3 : create  账户级别   高级别包含低级别的权限。

    下面介绍一下典型的SQL-DCL命令和应用:

    在前面的博客中由提过DCL包含两个关键词 Grant 和 Revoke 分别表示授权和取消授权,其基本语法如下:

    Grant {all privileges | privilege{,...}}    (其中privilege可为select读,insert,delete,update)

    On  [TABLE] tablename | viewname      (数据对象)

    To  {public | user-id{,.......}}                       (用户对象)

    [whth grant  option]; (该命令选项为许可权力传播,即该用户可将自己的权力许可给其他账户)

    对应的取消授权为:

    Revoke {all privileges | privilege{,...}}  on  tablename | viewname  From  {public | user-id{,.......}};

    以上为用户自定义的安全机制,对于数据库本身是有内部安全机制的,即:

    对关系:R(A1:D1,C1,.........An:Dn,Cn,TC)其中A1为属性,D1为域,C1为属性安全分类特性,TC为元组分类特性

    只有Level(S)大于等于Level(o)时才能对数据进行访问,

    而只有Level(S)小于等于Level(o)时才能对数据进行修改


    展开全文
  • 数据库并发机制和事务的隔离级别详解 本文将从以下4个方面来展开: (1)事务的4大特性: (2)数据库并发操作产生的问题: (3)数据库的锁机制: (4)事务的4大隔离级别:


     (尊重劳动成果,转载请注明出处:http://blog.csdn.net/qq_25827845/article/details/64444896冷血之心的博客)

    本文将从以下4个方面来展开:

    (1)事务的4大特性:

    • 原子性
    • 一致性
    • 隔离性
    • 持久性
    (2)数据库并发操作产生的问题:
    • 丢失更新
    • 脏读
    • 不可重复读
    • 幻读
    (3)数据库的锁机制:
    • 共享锁
    • 排他锁
    • 更新锁

    • 悲观锁
    • 乐观锁
    (4)事务的4大隔离级别:
    • read_uncommited (读未提交)
    • read_commited(读已提交)
    • repeatable_read (可重复读)
    • Serialization   (串行读)

     

    1、事务的4大特性:


          事务是用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。例如,在关系数据库中,一个事务可以是一条SQL语句、一组SQL语句或整个程序。
    事务和程序是两个概念。一般地讲,一个程序中包含多个事务。
    事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务,则由DBMS按缺省规定自动划分事 务。

    在SQL语言中,定义事务的语句有三条: 
    BEGIN TRANSACTION 
    COMMIT 
    ROLLBACK

    事务具有4个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

    • 原子性(Atomicity):事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。
    • 一致性(Consistency):事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。
    •  隔离性(Isolation):多个事务并发执行时,一个事务的执行不应影响其他事务的执行。
    •  持久性(Durability):一个事务一旦提交,他对数据库的修改应该永久保存在数据库中。

     

    2、数据库并发操作产生的问题:

    在多个事务并发做数据库操作的时候,如果没有有效的避免机制,就会出现种种问题。大体上有四种问题,归结如下:

    1、丢失更新:

    如果两个事务都要更新数据库一个字段X,X=100

    两个不同事物同时获得相同数据,然后在各自事务中同时修改了该数据,那么先提交的事务更新会被后提交事务的更新给覆盖掉,这种情况事务A的更新就被覆盖掉了、丢失了。


    2、脏读

    防止一个事务读到另一个事务还没有提交的记录。 如:

     

    事务读取了未提交的数据,事务B的回滚,导致了事务A的数据不一致,导致了事务A的脏读 !

    3、不可重复读


    一个事务在自己没有更新数据库数据的情况,同一个查询操作执行两次或多次的结果应该是一致的;如果不一致,就说明为不可重复读。还是用上面的例子


    这种情况事务A多次读取x的结果出现了不一致,即为不可重复读 。

     

    4、幻读

    事务A读的时候读出了15条记录,事务B在事务A执行的过程中 增加 了1条,事务A再读的时候就变成了 16 条,这种情况就叫做幻影读。


    不可重复读说明了做数据库读操作的时候可能会出现的问题。

     

    提醒:
    不可重复读的重点是修改:
    同样的条件,你读取过的数据,再次读取出来发现值不一样了
    幻读的重点在于新增或者删除:
    同样的条件,第 1 次和第 2 次读出来的记录数不一样

     

    3、数据库的锁机制:

    1、锁的两种分类方式

    (1)从数据库系统的角度来看,锁分为以下三种类型:

    mysql锁机制分为表级锁和行级锁,行级锁包括共享锁、排他锁和更新锁。

     独占锁,简称X锁(Exclusive Lock)
          独占锁锁定的资源只允许进行锁定操作的程序使用,其它任何对它的操作均不会被接受。执行数据更新命令,即INSERT、UPDATE 或DELETE 命令时,SQL Server 会自动使用独占锁。但当对象上有其它锁存在时,无法对其加独占锁。独占锁一直到事务结束才能被释放。

     

     共享锁,简称S锁(Shared Lock)
          共享锁锁定的资源可以被其它用户读取,但其它用户不能修改它。在SELECT 命令执行时,SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后,共享锁就会立即被释放。


     更新锁(Update Lock)
          更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时,它首先对数据对象作更新锁锁定,这样数据将不能被修改,但可以读取。等到SQL Server 确定要进行更新数据操作时,它会自动将更新锁换为独占锁。但当对象上有其它锁存在时,无法对其作更新锁锁定。

          对于共享锁大家可能很好理解,就是多个事务只能读数据不能改数据,对于排他锁大家的理解可能就有些差别,我当初就犯了一个错误,以为排他锁锁住一行数据后,其他事务就不能读取和修改该行数据,其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后,其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句,update,delete,insert都会自动给涉及到的数据加上排他锁,select语句默认不会加任何锁类型,如果加排他锁可以使用select ...for update语句,加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的,也不能通过for update和lock in share mode锁的方式查询数据,但可以直接通过select ...from...查询数据,因为普通查询没有任何锁机制。

     

    (2)从程序员的角度看,锁分为以下两种类型:

    悲观锁(Pessimistic Lock)
          悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。

     

    乐观锁(Optimistic Lock)
          相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
          而乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本( Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。

          常见实现方式:在数据表增加version字段,每次事务开始时将取出version字段值,而后在更新数据的同时version增加1(如: update xxx set data=#{data},version=version+1 where version=#{version} ),如没有数据被更新,那么说明数据由其它的事务进行了更新,此时就可以判断当前事务所操作的历史快照数据。

     

    4、事务的隔离级别:

     隔离级别:

    为了避免数据库事务操作中的问题,在标准SQL规范中,定义了4个事务隔离级别,不同的隔离级别对事务的处理不同:

      ◆读未提交(Read Uncommitted):允许脏读取,但不允许更新丢失。如果一个事务已经开始写数据,则另外一个数据则不允许同时进行写操作,但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。


      ◆读已提交(Read Committed):允许不可重复读取,但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。


      ◆可重复读(Repeatable Read):禁止不可重复读取和脏读取,但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。


      ◆序列化(Serializable):提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
      

           隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed,它能够避免脏读取,而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁或乐观锁来控制。

     

    隔离级别实现机制:


    x锁 排他锁 被加锁的对象只能被持有锁的事务读取和修改,其他事务无法在该对象上加其他锁,也不能读取和修改该对象
    s锁 共享锁 被加锁的对象可以被持锁事务读取,但是不能被修改,其他事务也可以在上面再加s锁。
     
    在运用X锁和S锁对数据对象加锁时,还需要约定一些规则 ,例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议(Locking Protocol)。对封锁方式规定不同的规则,就形成了各种不同的封锁协议。
      
       一级封锁协议 (对应 read uncommited)  
       一级封锁协议是:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。
       一级封锁协议可以防止丢失修改,并保证事务T是可恢复的。使用一级封锁协议可以解决丢失修改问题。   
       在一级封锁协议中,如果仅仅是读数据不对其进行修改,是不需要加锁的,它不能保证可重复读和不读“脏”数据。
      
       二级封锁协议 (对应read commited) 
       二级封锁协议是:一级封锁协议加上事务T在读取数据R之前必须先对其加S锁,读完后方可释放S锁 
       二级封锁协议除防止了丢失修改,还可以进一步防止读“脏”数据。但在二级封锁协议中,由于读完数据后即可释放S锁,所以它不能保证可重复读。
      
       三级封锁协议 (对应reapetable read )
       三级封锁协议是:一级封锁协议加上事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放。  
       三级封锁协议除防止了丢失修改和不读“脏”数据外,还进一步防止了不可重复读。

     

    锁和隔离级别的关系

            一般来说,实际开发中,直接操作数据库中各种锁的几率相对比较少,更多的是利用数据库提供的四个隔离级别,未提交读、已提交读、可重复读、可序列化,那隔离级别和锁是什么关系?通俗来说,隔离级别是锁的一个整体打包解决方案,我的理解是隔离封装了锁。


           隔离级别从上到下依次增加,级别越低,引起的问题也就比较多,比如脏读、丢失更新等,但等级越高,也就意味着需要管理更多的锁,无法并行处理,性能方面又受损,因此,我们在设计系统时,只需要根据业务需求选择一种当下适合的隔离级别。一种隔离级别,就有一套利用锁的方案,如此设计,目的就是为了平衡性能和功能。


    (多谢前人的总结)

    转载摘抄于以下网页:

    http://blog.csdn.net/tuolaji8/article/details/48549481

    http://blog.sina.com.cn/s/blog_44b84ae20100ak2r.html

    http://www.cnblogs.com/houweijian/p/5869243.html

    http://www.wujianjun.org/2016/05/27/transaction-isolation-levels/?utm_source=tuicool&utm_medium=referral

    http://harisxiong.blog.51cto.com/7513022/1351370

    http://www.cnblogs.com/adforce/archive/2011/04/20/2021929.html

    http://www.cnblogs.com/boblogsbo/p/5602122.html

     

     

    如果对你有帮助,记得点赞哦~欢迎大家关注我的博客,可以进群366533258一起交流学习哦~奋斗






    展开全文
  • 数据库机制(一)

    千次阅读 2019-03-29 02:21:37
    数据库的锁机制做了以下总结: 乐观锁 乐观锁就如同他的名字一样,当其他人(线程)去取数据的时候,总是认为别人不会修改数据,总不会发生并发问题,所以因此没有上锁,只有在线程提交数据时会通过检查版本号的...
  • 数据库的事务机制

    千次阅读 2017-10-01 13:45:42
    数据库的事务机制 为什么需要事务,并发访问数据会造成什么问题 事务的ACID原则 事务的隔离级别 数据库的锁机制 为什么需要锁,存在哪些锁 悲观锁 数据库的悲观锁有两种实现方式:共享锁和排它锁,根据锁的...
  • 数据库数据库的锁机制及原理

    万次阅读 多人点赞 2018-03-08 18:06:13
    数据库的锁机制,今天彻底理清楚。文章中有参考整理其他一些有价值的博客以及mysql官方文档的内容,如有侵权请联系删除。 数据库锁 先看一张图自己整理的数据库锁的树形图 概要 数据库锁一般可以分为两...
  • 我可以和大家共同分享我的知识,我陆续把我的你们需要的资料传上来
  • 数据库的锁机制

    千次阅读 2017-04-07 17:13:48
    咱们在数据库的“读现象”浅析中介绍过,在并发访问情况下,可能会出现脏读、不可重复读和幻读等读现象,为了应对这些问题,主流数据库都提供了锁机制,并引入了事务隔离级别的概念。并发控制在计算机科学,特别是...
  • 详解数据库机制和原理

    千次阅读 2020-07-13 15:55:10
    本文将基于 MySQL,介绍数据库机制,相信大家耐心看了之后肯定有收获,码字不易,别忘了「在看」,「转发」哦。 锁的类型 MyISAM 锁机制 InnoDB 锁机制 正文 01 锁的类型 从对数据的操作粒度来划分,MySQL 大致可...
  • 数据库安全其他机制

    千次阅读 2018-05-21 23:51:50
    一、视图机制 通过视图机制把要保密的数据对无权存取的用户隐藏起来,从而自动对数据提供一定程度的安全保护。 视图机制间接地实现支持存取谓词的用户权限定义。操作方法: 建立一个视图,授予用户相应的权限...
  • 【MySQL】--数据库机制

    千次阅读 2020-07-23 23:44:28
    锁是计算机协调多个进程或线程并发访问某一资源的机制。 在数据库中,除传统的计算资源(如CPU、RAM、I/O等)的争抢以外,数据也是一种供需多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须...
  • 数据库机制 很详细的教程,易懂

    万次阅读 多人点赞 2017-05-18 22:38:30
    看到网上大多语焉不详(尤其更新锁),所以这里做个简明解释,为下面描述方便,这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程。T3,T4以此类推。下面以SQL Server...
  • 机制数据库一个比较重要的机制,在处理事务的并发性方面起着至关重要的作用,我也看过好多关于锁机制的文章blog,什么悲观锁、乐观锁?什么共享锁、排他锁?还有什么行级锁、表级锁?另外还有读锁、写锁?oh,my...
  • SQL Server数据库机制及类型

    千次阅读 2009-02-18 16:55:00
    SQL Server数据库机制及类型 [06-05 12:08:14]作者:责任编辑:heyaorong Microsoft SQL Server(以下简称SQL Server)作为一种中小型数据库管理系统,已经得到了广泛的应用,该系统更强调由系统来管理锁。...
  • 数据库 安全机制 研究 论文 课程设计 数据库 安全机制 研究 论文 课程设计
  • 从区块链层次结构、访问控制过程的逻辑层次结构、访问控制的实现原理、访问控制的共识认证原理以及访问控制区块链体系的构建机制几个方面设计了基于区块链的数据库访问控制实现机制,对基于区块链的数据库访问控制...
  • Mysql 数据库的锁机制分析

    万次阅读 2019-09-04 20:10:51
    文章目录Mysql 数据库的锁机制分析一、问题背景1. 为什么要加锁?2.要解决的问题二、锁是什么三、锁的分类1.行级锁2.表级锁3.页级锁四、MySQL常用存储引擎的锁机制1. **`MyISAM`和`MEMORY`采用表级锁(table-level ...
  • 数据库系统安全机制

    万次阅读 2008-03-22 22:15:00
    1.1.4 数据库系统安全机制数据库安全机制是用于实现数据库的各种安全策略的功能集合,正是由这些安全机制来实现安全模型,进而实现保护数据库系统安全的目标。近年来,对用户的认证与鉴别、存取控制、数据库加密及...
  • 解决高并发(数据库机制)

    千次阅读 2018-10-18 09:42:41
    这篇文章介绍的特别好 https://www.cnblogs.com/lpyan/p/5607669.html
  • 设置SQL Server数据库AWE机制

    千次阅读 2017-09-11 18:03:00
    我们知道,在SQL Server数据库中,对...Server数据库的AWE机制以及对内存的支持,希望能够对您有所帮助。 症状:数据库服务器CPU100%,内存使用1/4(8G内存,只能用到2G,sqlservr.exe使用1.7G) 环境:Windows 20
  • 这个程序集中的知识:通过解析配置文件获得与数据库的链接,同时解析xml映射数据库表,其中还运用到了反射机制,同时通过已经映射的数据库表来达到对数据库的各种操作。
  • 数据库回滚机制(RollBack)的实现

    万次阅读 2016-11-28 20:45:47
    一、我们来看一个DML语句的处理过程描述 update undotest set object_type='VIEW' where object_type='PROCEDURE'; ...检查shared pool中是否存在相同的语句,如果存在,重用执行计划,执行扫描运算,如果不存在...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 843,384
精华内容 337,353
关键字:

数据库所机制