mysql事务

今天咱们说说事务，相信大家都知道事务的 ACID (Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性)。 原子性：表示一个事务不可在分割，而且事务中的操作要么一起成功，要么一起失败； 一致性：表示事务前后数据的完整性必须保持一致； 持久性：表示事务一旦进行提交，那么数据的就改便会永久保存，即使数据库出现宕机也不会任何影响。 前面三个很好理解，那咱们再说说事务的隔离性， 事务的隔离就是表示事务与事务之间不会相互干扰 。但是多事务的情况下，还是很容易出现脏读、不可重复读以及幻读的问题。我们简单的解释一下这几个词， 脏读：当数据库中一个事务A正在修改一个数据但是还未提交或者回滚，另一个事务B 来读取了修改后的内容并且使用了，之后事务A提交了，此时就引起了脏读。 此情况仅会发生在： 读未提交的的隔离级别. 不可重复读：在一个事务A中多次操作数据，在事务操作过程中(未最终提交)，事务B也才做了处理，并且该值发生了改变，这时候就会导致A在事务操作的时候，发现数据与第一次不一样了。 就是不可重复读。 此情况仅会发生在：读未提交、读提交的隔离级别. 幻读：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为幻读。幻读是指当事务不是独立执行时发生的一种现象

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

本文源码： GitHub·点这里 || GitEE·点这里 一、锁概念简介 1、基础描述 锁机制核心功能是用来协调多个会话中多线程并发访问相同资源时，资源的占用问题。锁机制是一个非常大的模块，贯彻MySQL的几大核心难点模块：索引，锁机制，事务。这里是基于MySQL5.6演示的几种典型场景，对面MySQL这几块问题时，有分析流程和思路是比较关键的。在MySQL中常见这些锁概念：共享读锁、排它写锁 ; 表锁、行锁、间隙锁。 2、存储引擎和锁 MyISAM引擎：基于读写两种模式，支持表级锁 ; InnoDB引擎：支持行级别读写锁，跨行的间隙锁,InnoDB也支持表锁 ; 3、锁操作API LOCK TABLE name [READ,WRITE] ;加表锁 UNLOCK TABLES ; 释放标所 二、MyISAM锁机制 1、基础描述 MySQL的表级锁有两种模式：共享读锁（Read-Lock）和排它写锁（Write-Lock）。针对MyISAM表的读操作，不会阻塞其他线程对同一表的读请求，但阻塞对同一表的写请求；针对MyISAM表的写操作，会阻塞其他线程对同一表的读和写操作；MyISAM引擎读写操作之间，以及写与写操作之间是串行化。当一次会话线程获取表的写锁后，只有当前持有锁的会话线程可以对表进行操作。其它线程的读、写操作都会等待，直到锁被释放为止。 2、验证案例

使用navicat测试学习: 首先使用set autocommit = 0;(取消自动提交,则当执行语句commit或者rollback执行提交事务或者回滚) 在打开一个执行update 查询 正在执行的事务： SELECT * FROM information_schema.INNODB_TRX 根据这个事务的线程ID（trx_mysql_thread_id）: 从上图看出对应的mysql 线程：一个94362 （第二个正在等待锁）另一个是93847(第一个update 正在执行 没有提交事务) 可以使用mysql命令：kill 线程id 杀掉线程 期间如果并未杀掉持有锁的线程：则第二个update语句提示等待锁超时 查询mysql数据库中还可以使用: 查看正在锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 查看等待锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 查询mysql数据库中存在的进程 [sql] view plain copy select * from information_schema.`PROCESSLIST`(show processlist;) 概念： mysql中database、instance、session。

事务处理之父Jim Gray对事务隔离性的定义： Isolation: Concurrently executing transactions see the stored information as if they were running serially (one after another). 事务的隔离级别从低到高有： Read Uncommitted ：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。 Read Committed ：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。 Repeated Read ：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。 Serialization ：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。 通常，在工程实践中，为了性能的考虑会对隔离性进行折中。 其中只有serialization实现隔离性所有要求，在真正实现事务的隔离性。 但考虑到实践，为了性能，数据库厂商做出了这方面的妥协，让使用者可以选择隔离的级别。 不同的隔离级别可以解决不同阶段的问题，是层层递进，逐渐增强的关系。 隔离性为了解决的问题主要有三个

网络上关于这方面的博文有些偏理论，有些通篇代码，都不能深入浅出。本文用图文并茂的方式，配上行云流水般的代码，非要摆清楚这个问题。相关代码已提交至码云（点击 这里 下载）。 事务是现代关系型数据库的核心之一。在多个事务并发操作数据库（多线程、网络并发等）的时候，如果没有有效的避免机制，就会出现以下几种问题： 第一类丢失更新（Lost Update） 在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务完成，另一事务异常终止，回滚造成第一个完成的更新也同时丢失 。这个问题现代关系型数据库已经不会发生，就不在这里占用篇幅，有兴趣的可以自行百度。 脏读（Dirty Read） A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下： 可以用EF Core模拟此过程： class TestReadUncommitted :TestBase { private AutoResetEvent _autoResetEvent; [Test] public void ReadUncommitted() { using (var context = _autofacServiceProvider.GetService

关系型数据库都具有一套事务级别，以前的开发和学习过程我很少关注过这个概念，今天搜集了一些资料，在 结合spring声明式事务学习的同时，总结一下数据库的事务级别与操作。 READ-UNCOMMITTED: 未提交读 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 ) READ-COMMITTED: 提交读 会出现不可重复读、幻读问题（锁定正在读取的行） REPEATABLE-READ: 可重复读 会出幻读（锁定所读取的所有行） SERIALIZABLE: 序列化 保证所有的情况不会发生（锁表） 详细说明： 未提交读 ——这通常称为 'dirty read'：non-locking SELECT 的执行使我们不会看到一个记录的可能更早的版本； 因而在这个隔离级别下是非 'consistent' reads；这级隔离级别的运作如同 READ COMMITTED。处于这个隔离级的 事务可以读到其他事务还没有提交的数据。如果这个事务使用其他事务未提交的变化作为计算的基础，然后那些未 提交的变化被他们的父事务撤销，则会导致误差。 提交读 ——在一个事务中已经COMMIT的数据可以在其他事务中看到。如果这个事务频繁提交的话，其他的大的查询 事务中可能会得到多个不同的结果。 可重复读 ——这是 InnoDB 默认的事务隔离级。在一个事务中所有读都是连续的。 序列化 —

一、事务隔离级别 　　在数据库系统中， 隔离 是定义一个操作对数据所做的改变如何/何时对其它的 并行 操作可见。　　 　　在数据库操作中， 为了有效保证并发读取数据的正确性 ，提出的事务隔离级别。 　　事务隔离级别：一个事务对数据库的修改与并行的另一个事务的隔离程度。　　 二、事务并发执行涉及到的问题 　　数据库是要被广大客户所共享访问的，那么在数据库操作过程中很可能出现以下几种不确定情况： 　　脏读(Drity Read)：某个事务已更新一份数据还未提交，另一个事务在此时读取了同一份数据，由于某些原因，前一个事务RollBack了操作，则后一个事务所读取到的数据就会是不正确的。 　　不可重复读(Non-repeatable read):在一个事务的两次相同查询中数据不一致，这可能是两次查询过程中间插入了另一个事务更新了原有的数据。也可以说：事务T1读取某一数据后还未提交，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。 　　幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 三、解决方法--4类事务隔离级别 　　SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的

Mysql相关 mysql增删改查 我们需要修改数据表名或者修改数据表字段时，就需要使用到Mysql Alter命令 删除，添加或修改表字段 alter table student drop register_date; #从student表删除register_date alter table student add phone int(11) not null; #添加phone字段 修改字段类型及名称 如果需要修改字段类型及名称，你可以在alter命令中使用Modify或change 例如：把字段c的类型从char(1)改为char(10)，可以执行以下命令: alter table testalter_tbl modigy c char(10); 使用change子句，语法有很大的不同。在change关键字之后，紧跟着的是你要修改的字段名，然后指定新字段名及类型。 alter table testalter_tbl change i j BIGINT; alter table testalter_tbl change j j int; alter table对null值和默认值的影响 当你修改字段时，你可以指定是否包含只或者是否设置默认值 以下实例，指定字段j为not null且默认值为100 alter table testalter_tbl modify j

隔离性 mysql提供了4种不同的隔离级别以支持多版本并发控制(MVCC) 较低级别的隔离通常可以执行更高的并发,系统的开销也更低 read uncommited(未提交读) read commited(提交读) repeatable read(可重复读) serializable(可串行化) 默认repeatable-read 建议最好不要修改默认的隔离级别,修改隔离级别会对mysql复制产生影响 isolation-table.sql DROP TABLE IF EXISTS transaction_test; CREATE TABLE transaction_test( id INT UNSIGNED NOT NULL AUTO_INCREMENT, val VARCHAR(20) NOT NULL, created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY(id) ) ENGINE=InnoDB DEFAULT CHARSET latin1; #初始化数据 insert into transaction_test(val) values ('a'),('b'),('c'); 1.REPEATABLE-READ(可重复读) 解决了脏读问题.该级别保证了在同一事物中多次读取同样的记录结果是一样的