数据库事务

概念 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！ 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。 一般来说，事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability） 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化

MongoDB 4.2已经发布，我们来看看它增加了哪些新特性？分布式事务？数据库加密？通配符索引？ 在2019年MongoDB World大会上，CTO Eliot Horowitz介绍了MongoDB 4.2中的一些功能，这些功能扩展了其在数据库技术方面的领先地位：分布式事务（Distributed Transactions），字段级加密（Client Side Field Level Encryption），通配符索引（Wildcard Indexing）、按需物化视图（Materialized Views）。 这些都是重大的改进，表明MongoDB在企业级功能方便更加完善。 MongoDB 4.2提升了事务和分析技术水平。它提供大规模的分布式事务的ACID担保和复杂的数据处理流程，还有最先进的加密控制保护机制。我们可以在任何地方运行MongoDB4.2：在本地数据中心，云上、混合云、Atlas云上。我们可以获得阿里云、AWS，Azure和GCP可用的完全托管，云原生的MongoDB服务。阿里云全球第一个实现了MongoDB异地多活架构。可以支持互联网跨国公司的大规模出海业务。 现在使用MongoDB的公司越来越多了，技术架构方案也越来越成熟。MongoDB新特性也是为了满足更多的企业级业务场景需求。 1. MongoDB 4.2 新特性 先来大体上看看有哪些改进，作为4

一.事务基本概念及特性 1. 事务定义与详解 事务是数据库系统中重要的概念，事务的定义：是构成单一逻辑工作单元的操作集合。 一个典型的数据库事务如下所示： BEGIN TRANSACTION //事务开始 SQL1 SQL2 COMMIT/ROLLBACK //事务提交或回滚 关于定义的解释： 数据库事务可以包含一个或多个数据库操作，这些操作构成一个逻辑上的整体。 对于一个事务来说，上述构成的逻辑整体具有原子性，要么全部执行，要么均不 执行。 数据库出现故障以及并发事务存在的情况下依然成立 2.事务4大特性(ACID) 原子性(Atomicity) 事务中所有操作可作为一个整体像原子一样不可分割，要么全部执行成功，要么 全部执行失败。 一致性(Consistency) 指系统数据在事务执行前后，若事务执行成功从一个正确状态迁移到另一个正确 状态。如果失败，回滚到初始时的正确状态。正确状态是指数据当前的状态满足预定的约束，约束既有数据完整性约束(主键等)也有开发者制定业务上的。 隔离性(Isolation) 指在并发环境下，当不同的事务同时操作相同的数据时，每个事务都有各自完整的数据空间，多个事务之间要相互隔离，隔离级别下文再详细介绍。 持久性(Durability) 指事务一旦被提交，它对数据库中的数据的改变就必须永久保存下来，即使发生系统崩溃

悲观锁(Pessimistic Lock) 顾名思义，就是 很悲观 ，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型 数据库 里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 我们认为 系统 中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。 乐观锁(Optimistic Lock) 顾名思义，就是 很乐观 ，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 我们认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。它的基本思想就是每次提交一个事务更新时，我们想看看要修改的东西从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。 两种锁的比较 两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下

背景 当用户并发尝试访问同一数据的时，SQL Server尝试用锁来隔离不一致的数据和使用隔离级别查询数据时控制一致性(数据该如何读取)，说起锁就会联想到事务，事务是一个工作单元，包括查询／更新数据和数据定义。 锁 锁类型 在SQL Server中，根据资源的不同，锁分为以下三种类型： 行锁：是SQL Server中数据级别中粒度最小的锁级别，行锁根据表是否存在聚集索引，分为键值锁和标识锁 页锁：针对某个数据页添加的锁，在T-SQL语句中，使用了页锁就不会在使用相同类型的行锁，反之依然，在对数据页加锁后，无法在对其添加不兼容的锁 表锁：添加表锁则无法添加与其不兼容的页å锁和行锁 锁模式 共享锁(S)：发生在数据查找之前，多个事务的共享锁之间可以共存 排他锁(X)：发生在数据更新之前，排他锁是一个独占锁，与其他锁都不兼容 更新锁(U)：发生在更新语句中，更新锁用来查找数据，当查找的数据不是要更新的数据时转化为S锁，当是要更新的数据时转化为X锁 意向锁：发生在较低粒度级别的资源获取之前，表示对该资源下低粒度的资源添加对应的锁，意向锁有分为：意向共享锁(IS) ，意向排他锁(IX)，意向更新锁(IU)，共享意向排他锁(SIX)，共享意向更新锁(SIU)，更新意向排他锁(UIX) 共享锁／排他锁／更新锁一般作用在较低级别上，例如数据行或数据页，意向锁一般作用在较高的级别上，例如数据表或数据

锁机制 NOLOCK 和 READPAST 的区别。 1. 开启一个事务执行插入数据的操作。 BEGIN TRAN t INSERT INTO Customer SELECT 'a' , 'a' 2. 执行一条查询语句。 SELECT * FROM Customer WITH ( NOLOCK ) 结果中显示 ”a” 和 ”a” 。当 1 中事务回滚后，那么 a 将成为脏数据。 ( 注 :1 中的事务未提交 ) 。 NOLOCK 表明没有对数据表添加共享锁以阻止其它事务对数据表数据的修改。 SELECT * FROM Customer 这条语句将一直死锁，直到排他锁解除或者锁超时为止。 ( 注 : 设置锁超时 SET LOCK_TIMEOUT 1800) SELECT * FROM Customer WITH ( READPAST ) 这条语句将显示 a 未提交前的状态，但不锁定整个表。这个提示指明数据库引擎返回结果时忽略加锁的行或数据页。 3. 执行一条插入语句。 BEGIN TRAN t INSERT INTO Customer SELECT 'b' , 'b' COMMIT TRAN t 这个时候，即使步骤 1 的事务回滚，那么 a 这条数据将丢失，而 b 继续插入数据库中。 NOLOCK 1． 执行如下语句。 BEGIN TRAN ttt SELECT * FROM

写在前面:本节主要谈谈SQLite的锁机制，SQLite是基于锁来实现并发控制的，所以本节的内容实际上是属于事务处理的，但是SQLite的锁机制实现非常的简单而巧妙，所以在这里单独讨论一下。如果真正理解了它，对整个事务的实现也就理解了。而要真正理解SQLite的锁机制，最好方法就是阅读SQLite的源码，所以在阅读本文时，最好能结合源码。SQLite的锁机制很巧妙，尽管在本节中的源码中，我写了很多注释，也是我个人在研究时的一点心得，但是我发现仅仅用言语，似乎不能把问题说清楚，只有通过体会，才能真正理解SQLite的锁机制。好了，下面进入正题。 SQLite的并发控制机制是采用加锁的方式，实现非常简单，但也非常的巧妙，本节将对其进行一个详细的解剖。 请仔细阅读下图，它可以帮助更好的理解下面的内容。 1、RESERVED LOCK RESERVED锁意味着进程将要对数据库进行写操作。某一时刻只能有一个RESERVED Lock，但是RESERVED锁和SHARED锁可以共存，而且可以对数据库加新的SHARED锁。 为什么要用RESERVED锁？ 主要是出于并发性的考虑。 由于SQLite只有库级排斥锁（EXCLUSIVE LOCK），如果写事务一开始就上EXCLUSIVE锁，然后再进行实际的数据更新，写磁盘操作，这会使得并发性大大降低。而SQLite一旦得到数据库的RESERVED锁

当多个事务在数据库中并发执行时，数据的一致性可能受到破坏。系统有必要控制各事务之间的相互作用，这是通过并发控制机制的多种机制中的一种来实现的。 避免事务"饿死"，授权加锁的条件：不存在在数据项Q上持有与M型锁冲突的锁的其他事务；不存在等待对数据项Q加锁且先于Ti申请加锁的事务。 常用的机制是各种封锁协议，时间戳排序，有效性检查，多版本机制。 封锁协议是一组阐明了事务合适对数据库中的数据项加锁解锁的规则。 两阶段封锁协议 仅在一个事务未曾释放任何数据项时允许该事务封锁新数据项。该协议保证可串行性，但不能避免死锁。在缺少有关数据项存取方式的信息是，两阶段封锁协议对保证可串行化来说不仅是必要的而且是充分的。 树形协议 规则：1、Ti的首次加锁可以对任何数据项进行。2、此后Ti对数据项Q加锁的前提是Ti持有Q的父项上的锁。3、对数据项解锁可以随时进行。4、数据项被Ti加锁并解锁后，Ti不能再对该数据项加锁。 时间戳排序机制 通过事先在每对事务之间选择一个顺序来保证可串行性。系统中的每个事务对应一个唯一的固定的时间戳。事务的时间戳决定了事务的可串行化顺序。这样，如果事务Ti的时间戳小于事务Tj时间戳，则该机制保证产生的调度等价于事务Ti出现在事务Tj之前的一个串行调度。该机制通过回滚违反该次序的事务来保证这一点。 Thomas写规则： 假设事务Ti发出write(Q)操作： 1、若TS（Ti

说到事务一定会提到ACID，所谓事务的原子性，一致性，隔离性和持久性。对于一个数据库而言，通常通过并发控制和故障恢复手段来保证事务在正常和异常情况下的ACID特性。sqlite也不例外，虽然简单，依然有自己的并发控制和故障恢复机制。 Sqlite学习笔记(五)&&SQLite封锁机制 已经讲了一些锁机制的原理，本文将会详细介绍一个事务从开始，到执行，最后到提交所经历的过程，其中会穿插讲一些sqlite中锁管理，缓存管理和日志管理的机制，同时会介绍在异常情况下(软硬件故障，比如程序异常crash，主机掉电等)，sqlite如何将数据库恢复到事务之前的状态。本文大量参考了sqlite的官方文档，结合自己的理解，希望能把这个过程说清楚。 1.事务提交 1.1 开启一个事务 在向数据库文件写数据前，sqlite首先需要访问sqlite_master表获取元数据信息，用来对SQL语句进行语义分析，判断语句的合法性。从数据库读数据第一步，是对数据库文件上一个Shared Lock。Shared Lock允许多个事务同时读一个数据库文件，但是Shared Lock会阻止写事务向数据库文件写入数据。 1.2 读数据 获取Shared Lock后，我们可以从数据库文件中读取数据了。我们假设缓存中没有我们的page，因此需要通过读文件读取我们需要的page。这里说明下

简介 SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统。它的设计目标是嵌入式的，目前Android和iOS的设备内置的都是SQLite数据库。SQLite虽然娇小，但也支持事务和多数的SQL92标准。 主要特点 Zero-Configuration 无需安装和管理配置。 Serverless 无需服务器支持。 Single Database File 数据文件存储在一个单一的磁盘文件。 Stable Cross-Platform Database File 数据库文件格式跨平台，无论是大小端，或者是32bit或64bit机器都没有关系 Compact 完整特性的SQLite编译出来在500KiB左右，裁剪特性甚至可以得到低于300KiB的库（当前版本3.8.11.1）。 Manifest typing 可以声明数据库字段类型，但是字段存储的类型实际的存储类型和实际值相关，单独的一个字段可能包含不同存储类的值。 Variable-length records 可变长度记录，例如你存储一个字符到VARCHAR(100) 的列，实际需要的存储空间一个字符加一个字节的存储空间。 SQL statements compile into virtual machine code SQL语句会被编译成虚拟机代码，这种虚拟机代码直白可读，便于调试。 Public domain