189 8069 5689
分别是原子性、一致性、隔离性、持久性。
创新互联专注于企业网络营销推广、网站重做改版、埇桥区网站定制设计、自适应品牌网站建设、H5开发、商城建设、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为埇桥区等各大城市提供网站开发制作服务。
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
隔离性是当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。
在数据库操作中，在并发的情况下可能出现如下问题：
正是为了解决以上情况，数据库提供了几种隔离级别。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。
虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。
悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。
商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。
如果不采用锁，那么操作方法如下：
但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步操作中，查询出来的商品status为1。但是当我们执行第三步Update操作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。
在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0;
设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：
上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。
上面的第一步我们执行了一次查询操作： select status from t_items where id=1 for update; 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一个数据时才会等待其它事务结束后才执行，一般 SELECT ... 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update; 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update; 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1; 则能正常查询出数据，不会受第一个事务的影响。
使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：
1、 select * from t_items where id=1 for update;
这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。
2、 select * from t_items where id=3 for update;
这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。
3、 select * from t_items where name='手机' for update;
这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。
4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; （注：在SQL中表示不等于）
上述两条语句的主键都不明确，也会产生table lock。
5、 select * from t_items where status=1 for update; （假设为status字段添加了索引）
这条语句明确指定了索引，并且有此数据，则产生row lock。
6、 select * from t_items where status=3 for update; （假设为status字段添加了索引）
这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：
当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性：
MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务。为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制
事务执行时需要将执行的事务日志写入日志文件，对应的文件为 REDO 日志。当每条 SQL 进行数据更新操作时，首先将 REDO 日志写进日志缓冲区。当客户端执行 COMMIT 命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制
REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB，建议设置为 512MB，以便容纳较大的事务。MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性
与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区，然后在合适的时间将内容刷新到磁盘
假如由于系统错误或者 rollback 操作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性
与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中，即使 MySQL 服务启动了独立表空间
在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务
MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少
InnoDB 系统级事务隔离级别可以使用以下语句设置：
查看系统级事务隔离级别：
InnoDB 会话级事务隔离级别可以使用以下语句设置：
查看会话级事务隔离级别：
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读（Dirty Read），即是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象
所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务，A事务读取了 B 事务的数据，在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果
MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read）。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行
InnoDB 通过多版本并发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果
通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用
为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询操作，需要对并发操作进行控制，因此产生了锁
共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读操作
排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写操作
有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务 A 释放共享锁之后。如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后
意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行操作但还没真正执行
锁的粒度主要分为表锁和行锁
表锁的开销最小，同时允许的并发量也是最小。MyISAM 存储引擎使用该锁机制。当要写入数据时，整个表记录被锁，此时其他读/写动作一律等待。一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁
行锁可以支持最大的并发，InnoDB 存储引擎使用该锁机制。如果要支持并发读/写，建议采用 InnoDB 存储引擎
MySQL 事务
什么是事务？
MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！
在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。
事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
事务用来管理 insert,update,delete 语句
一般来说，事务是必须满足4个条件（ACID）：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。
原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。
from 树懒学堂 - 一站式数据知识平台
默认情况下, MySQL启用自动提交模式（变量autocommit为ON）
如果是全局级别，则需要加global，如果是会话级别，则需要加session，如果都没加，默认是session。
全局变量作用域：服务器每次启动将为所有的全局变量赋初始值，修改全局变量针对于所有的会话（连接）有效，但不能跨重启（重启服务器全局变量恢复为默认值）。
会话变量作用域：仅仅针对于当前会话（连接）有效
查询会话事务提交模式：
show session variables like 'autocommit';
查询全局事务提交模式：
show global variables like 'autocommit';
Value的值为ON，表示autocommit开启。OFF表示autocommit关闭。
set global autocommit=0;
set SESSION autocommit=0;
禁止自动提交
SET AUTOCOMMIT=0
开启自动提交:
SET AUTOCOMMIT=1
查询 正在执行的事务：
SELECT * FROM information_schema.INNODB_TRX
查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
结束正在执行的事务：
使用mysql命令杀掉线程：kill 线程id （trx_mysql_thread_id）
手动提交模式：
BEGIN;
SQL；
COMMIT;
6.7 MySQL 事务与锁定命令
6.7.1 BEGIN/COMMIT/ROLLBACK 句法
缺省的，MySQL 运行在 autocommit 模式。这就意味着，当你执行完一个更新时，MySQL 将立刻将更新存储到磁盘上。
如果你使用事务安全表 (例如 InnoDB、BDB)，通过下面的命令，你可以设置 MySQL 为非 autocommit 模式：
SET AUTOCOMMIT=0
在此之后，你必须使用 COMMIT 来存储你的更改到磁盘上，或者使用 ROLLBACK ，如果你希望忽略从你的事务开始所做的更改。
如果你希望为一系列语句从 AUTOCOMMIT 模式转换，你可以使用 START TRANSACTION 或 BEGIN 或 BEGIN WORK 语句：
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;
COMMIT;
START TRANSACTION 在 MySQL 4.0.11 中被加入；这是被推荐的开始一个特别(ad-hoc)事务的方式，因为这是 ANSI SQL 句法。
注意，如果你使用的是一个非事务安全表，更改会立刻被存储，不受 autocommit 模式状态的约束。
当你更新了一个非事务表后，如果你执行一个 ROLLBACK，你将得到一个错误 (ER_WARNING_NOT_COMPLETE_ROLLBACK) 作为一个警告。所有事务安全表将被恢复，但是非事务安全表将不会改变。
如果你使用 START TRANSACTION 或 SET AUTOCOMMIT=0，你应该使用 MySQL
二进制日志做备份以代替老的更新日志。事务处理被以一个大块形式存储在二进制日志中，在 COMMIT
上面，为了保护回滚的事务，而不是被存储的。查看章节 4.9.4 二进制日志。 如果您使用起动事务处理或集AUTOCOMMIT=0
，您应该使用MySQL 二进制日志为备份代替更旧的更新日志。 事务处理存储在二进制登录一大块，做，保证, 滚的事务处理不存储。 参见部分4
。9.4 二进制日志。
下列命令自动的结束一个事务 (就好像你在执行这个命令之前，做了一个 COMMIT)：
命令 命令 命令
ALTER TABLE BEGIN CREATE INDEX
DROP DATABASE DROP TABLE RENAME TABLE
TRUNCATE
你可以使用 SET TRANSACTION ISOLATION LEVEL ... 改变事务的隔离级。查看章节 6.7.3 SET TRANSACTION 句法。
6.7.2 LOCK TABLES/UNLOCK TABLES 句法
LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
[, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} ...]
...
UNLOCK TABLES
LOCK TABLES 为当前线程锁定表。UNLOCK TABLES 释放当前线程拥有的所有锁定。当线程发出另一个 LOCK TABLES，或当与服务器的连接被关闭时，被当前线程锁定的所有表将被自动地解锁。
为了在 MySQL 4.0.2 使用 LOCK TABLES ，你必须拥有一个全局的 LOCK TABLES 权限和一个在相关表上的
SELECT 权限。在 MySQL 3.23 中，你对该表需要有 SELECT、insert、DELETE 和 UPDATE 权限。
使用 LOCK TABLES 的主要原因是，仿效事务处理或在更新表时得到更快的速度。此后会有更详细的描述。
如果一个线程在一个表上得到一个 READ 锁，该线程 (和所有其它线程) 只能从表中读取。如果一个线程在一个表上得到一个 WRITE 锁，那么只有拥有这个锁的线程可以从表中读取和写表。其它的线程被阻塞。
READ LOCAL 和 READ 之间的不同就在于，当锁被加载时，READ LOCAL 允许非冲突(non-conflicting) INSERT 语句执行。如果当你加载着锁时从 MySQL 外部操作数据库文件，这将仍不能被使用。
当你使用 LOCK TABLES 是地，你必须锁定所有你将使用的表，并且必须使用与你的查询中将使用的别名相同！如果你在一个查询中多次使用一个表(用别名)，你必须为每一个别名获得一个锁。
WRITE 锁通过比 READ 锁有更高的权限，以确保更新被尽快地处理。这就意味着，如果一个线程获得一个 READ
锁，而同时另外一个线程请求一个 WRITE 锁，并发的 READ 锁请求将等待直到 WRITE 线程得到了锁并释放了它。你可以使用
LOW_PRIORITY WRITE 锁，当该线程在等待 WRITE 锁时，它将允许其它的线程获得 READ 锁。 你应该只使用
LOW_PRIORITY WRITE 锁，如果你确信这将是最后一次，当没有线程将拥有 READ 锁。
LOCK TABLES 工作如下：
以内部定义的次序排序所有被锁定的表 (从用户立场说，该次序是不明确的)。
如果一个表被以一个读锁和一个写锁锁定，将写锁放在读锁之前。
一次只锁定一个表，只到线程得到所有的锁定。
这个方案是为了确保，表锁定死锁释放。 对于这个模式你仍然有些其它事情需要知道：
如果你对一个表使用一个 LOW_PRIORITY WRITE 锁定，这就意味着，MySQL 将等待这个锁，直到没有线程请求一个 READ
锁。当线程得到了 WRITE 锁，并等待获得锁定表列表中的下一个表的锁定时，其它所有的线程将等待 WRITE
锁被释放。如果这在你的应用程序中会引起一个严重的问题，你应该考虑将你的某些表转换为事务安全表。
你可以使用 KILL 安全地杀死一个正在表锁定的线程。查看章节 4.5.5 KILL 句法。
注意，你不应该 锁定你正在对其使用 INSERT DELAYED 的表。这是因为，在这种情况下，INSERT 是通过单独的线程完成的。
通常，你不需要锁定任何表，因为所有单 UPDATE 语句都是原子的；其它的线程无法干扰当前执行的 SQL 语句。当你无论如何希望锁定表时，这里有一些情况：
如果你在一束表上运行许多操作，锁定你将要使用的表，这会更快一些。当然有不利的方面，其它线程将不能更新一个 READ
锁的表，并且没有其它线程要以读取一个 WRITE 锁的表。 在 LOCK TABLES 下，某些事运行得更快一些的原因是，MySQL
将不会转储清除被锁定表键高速缓冲，直到 UNLOCK TABLES 被调用 (通常键高速缓冲在每个 SQL 语句后都会被转储清除)。这将加速在
MyISAM 表上的插入、更新、删除。
如果你在 MySQL 中正在使用一个不支持事务的存储引擎，如果你希望能确保没有其它的线程会出现在一个 SELECT 和 一个 UPDATE 之间，你必须使用 LOCK TABLES 。下面的示例显示为了安全地执行，这里需要LOCK TABLES ：
mysql LOCK TABLES trans READ, customer WRITE;
mysql SELECT SUM(value) FROM trans WHERE customer_id=some_id;
mysql UPDATE customer SET total_value=sum_from_previous_statement
- WHERE customer_id=some_id;
mysql UNLOCK TABLES;
不使用 LOCK TABLES，将可能发生在 SELECT 和 UPDATE 语句执行期间有另外一个线程可能在 trans 表中插入一行新记录。
通过使用递增更新 (UPDATE customer SET value=value+new_value) 或 LAST_INSERT_ID() 函数，你可以在很多情况下避免使用 LOCK TABLES。
你也可以使用用户级锁定函数 GET_LOCK() 和 RELEASE_LOCK() 解决一些情况，这些锁被保存在服务器上的一个哈希表中，并以
pthread_mutex_lock() 和 pthread_mutex_unlock() 实现以获得高速度。查看章节 6.3.6.2
辅助功能函数。
查看章节 5.3.1 MySQL 如何锁定表，以获取关于锁定方案的更多信息。
你可以使用 FLUSH TABLES WITH READ LOCK 命令以读锁锁定所有数据库中的所有表。查看章节 4.5.3 FLUSH 句法。如果你有一个可以及时建立文件快照的文件系统，例如 Veritas，这将是得到备份的非常方便方式。
注意：LOCK TABLES 不是事务安全的，在尝试锁定一个表之前，将自动地提交所有的活动事务。
6.7.3 SET TRANSACTION 句法
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
设置全局的、整个会话或下一个事务的事务隔离级。
缺省行为是设置下一个(未启动的)事务的隔离级。如果你使用 GLOBAL
关键词，语句为所有在那个点上建立的新连接设置默认的全局事务隔离级。为了这样做，你需要有 SUPER 权限。使用 SESSION
关键词为当前连接所有将来执行的事务设置默认的事务隔离级。
你可以使用 --transaction-isolation=... 为 mysqld 设置默认的全局隔离级。查看章节 4.1.1 mysqld 命令行选项
事务能保证你做的一系列动作，要么全部成功。如果有一个操作失败，就回退到修改前。 比如你要做下面几个操作， 1.删除表A中的某些记录 2.向B添加一些记录。 3.修改C表中的一些数据。 使用事务，如果1,2都成功了，3却失败了。就会回退到第1步执行前的样子，ABC表都没被修改。