mysql长事务有什么影响_MySQL的事务隔离级别和长事务，
看这⼀篇就够了
提到事务，⼤家都不陌⽣，在使⽤数据库的时候，我们总会提到事务，最经典的例⼦就是转帐，⽐如⼩王的银⾏卡上有⼀百块，要把这⼀百块转账，转账过程中的⼀系列操作，⽐如查询余额、扣减资⾦、增加资⾦、更新余额等，这些操作必须保证是⼀体的，不然等查询余额之后，在扣除资⾦之前，完全可以借着这个时间再查⼀次，然后将这个钱转给另外⼀个⼈，这样不就乱套了。
事务的概念各位都不陌⽣，简单来说，事务就是要保证⼀组数据库操作，要么全部成功，要么全部失败。MySQL数据库的事务⽀持是在引擎层实现的。MySQL是⼀个⽀持多引擎的系统，但是不是所有的引擎都⽀持事务，只有InnoDB⽀持事务。
隔离性与隔离级别
⼤家都都知道事务的四种属性ACID，今天我们就说说其中的 I，也就是隔离性。
数据库多个事务同时执⾏的时候，就会出现脏读(dirty read)、幻读(phantom read)、不可重复读 (non-repeatable read)等问题，为了解决这些问题，就有了隔离级别的概念。
事务的隔离等级越⾼，效率就会越低，很多时候我们就在数据准确和效率之间平衡点。SQL标准的事务隔离级别包括：读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串⾏化(serializable)。可能很多⼈已经对这⼏个概念很熟悉，这⾥就简单介绍⼀下：读未提交：⼀个事务还没提交时，它做的变更就能被其他事务看到。
读提交：⼀个事务只有在提交之后，其它事务才能看到它做的变更。
可重复读：⼀个事务执⾏过程中看到的数据，总是跟这个事务在启动时看到的数据是⼀致的，在可重复读隔离级别下，未提交变更对其它事务也是不可见的。
串⾏化：顾名思义是对同⼀⾏记录，“写”会加“写锁”，“读”会加“读锁”，当读写锁冲突的时候，后访问的事务必须等前⼀个事务执⾏完成才能继续执⾏。
下边通过⼀个例⼦来说明⼏个隔离级别，先准备⼀张表T，其中⼀⾏的值为1 ，按照时间顺序执⾏两个事务的⾏为：
mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);
下边我们来看看不同的隔离级别下，事务A的各个查询的结果，也就是V1，V2，V3的返回值分别是什么。隔离级别是“读未提交”，则
V1的值是2，这个时候虽然事务B还没有提交，但是结果已经被事务A看到了，所以V2，V3也都是2.
隔离级别是“读提交”，则V1的值是1，查询V2的时候事务B已经提交，所以事务B的更新事务A是可以看到的，所以V２是２，Ｖ３也是２。
隔离级别是“可重复读”，则V1、V2是1，V3是2，为什么V2还是1，是因为事务在执⾏期看到的数据前后必须是⼀致的。
隔离级别是“串⾏化”，在事务B执⾏将1改为2的时候，会被锁住，等事务A执⾏完提交后，事务B才可以继续执⾏，所以从事务A的⾓度来看，V1、V2值是1，V3的值是2.
在实现上，数据库⾥⾯会创建⼀个视图，访问的时候以视图的逻辑为准，在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都⽤整个视图。在“读提交“隔离级别下，这个视图是在每个SQL语句开始执⾏的时候创建的。”读未提交“隔离级别下直接返回记录上的最新值，没有视图概念。⽽”串⾏化“隔离级别下直接⽤加锁的⽅式来避免并⾏访问。
我们可以根据需要来修改MySQL的隔离级别，如我们要将MySQL的隔离级别设置为”读提交“，配置的
⽅式是，将启动参数transaction-isolation的值设置成READ-COMMITTED，可以⽤show variables来查看当前的值。
mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
事务隔离的实现
上边我们了解了事务的隔离级别，我们再来看看事务隔离具体是怎么实现的。这⾥我们来详细说说”可重复读“，在MySQL中，实际上每条记录在更新的时候都会同时记录⼀条回滚操作，记录上的最新值，通过回滚的⽅式都可以得到前⼀个状态的值。
mysql删除重复的数据保留一条
假设⼀个值从1被依次改成了2、3、4，在回滚⽇志(undo log)⾥就会有类似下边的记录。
当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view，如图中看到的，在视图A、B、C⾥⾯，这个记录的值分别是1、2、4，同⼀条记录在系统中可以存在多个版本，就是数据库的多版本并发控制(MVCC)。对于read-viewA，要想得到1，就必须将当前值依次执⾏图中所有的回滚操作得到。
这个时候你会发现，即使现在另外⼀个事务正在将4改为3，这个事务跟read-viewA、B、C对应的事务是不会冲突的。
回滚⽇志的保留时间，在不需要的时候才会删除，系统判断，没有其他事务线程还在使⽤当前版本的undo的时候，purge进程进⾏回收。
基于上边的说明，我们来讨论⼀下⼤佬们常说的尽量不使⽤长事务是为什么？
长事务意味着系统⾥⾯会存在很⽼的事务视图，由于这些事务随时可能访问数据库⾥⾯的任何数据，所以这个事务提交之前，数据库⾥⾯它可能⽤到的回滚记录都必须保留，这就导致了⼤量占⽤内存。在MySQL5.5以前的版本，回滚⽇志是和数据字典⼀起放在ibdata⽂件⾥的，即使长事务提交，回滚段被清理，⽂件也不会变⼩，最终往往为了清理回滚段⽽重建整个库。除了影响回滚段，长事务还会占⽤锁资源，也有可能拖垮整个库。
事务的启动⽅式
长事务的潜在风险我们上边已经聊过了，建议是尽可能的避免，其实很多长事务，并不是有意使⽤，都是被误⽤所致，下边我们聊聊MySQL的事务启动⽅式：显⽰启动事务语句，begin或者start transaction。配套的提交语句是commit，回滚语句是rollback。
set autocommit = 0，这个命令会将这个线程的⾃动提交关掉，意味着如果你只执⾏⼀个select语句，这个事务就启动了，⽽且不会⾃动提交，这个事务会⼀直持续存在直到你主动执⾏commit或者rollback语句，或者断开连接。
有⼀些客户端连接框架会默认连接成功后执⾏⼀个set autocommit = 0命令，这就导致了接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。因此，建议使⽤set autocommit=1，通过显式语句的⽅式来启动事务。
有的朋友会纠结”多⼀次交互“的问题，对于⼀个频繁使⽤事务的业务，第⼆种⽅式，每个事务在开始时都不需要主动执⾏⼀
次”begin“，减少了语句的交互次数，如果你也有这个顾虑，可以使⽤commit work and chain语法。
autocommit为1的情况下，⽤begin显式启动事务，如果执⾏commit，则提交事务，如果执⾏commit w
ork and chain，则是提交事务并开启下⼀个事务，减少了begin的开销。同时从程序开发的⾓度明确知道每个语句是否处于事务中。
你可以在 information_schema 库的 innodb_trx 这个表中查询长事务，⽐如下⾯这个语句，⽤于查持续时间超过 60s 的事务。
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
最后，我们可以通过尝试回答以下⼏个问题，来检查⾃⼰的掌握程度;
1.事务的概念是什么?
3.读已提交, 可重复读是怎么通过视图构建实现的?
4.可重复读的使⽤场景举例? 对账的时候应该很有⽤?
5.事务隔离是怎么通过read-view(读视图)实现的?
6.并发版本控制(MCVV)的概念是什么, 是怎么实现的?
7.使⽤长事务的弊病? 为什么使⽤常事务可能拖垮整个库?
8.事务的启动⽅式有哪⼏种?
9mit work and chain的语法是做什么⽤的?
10.怎么查询各个表中的长事务?
11.如何避免长事务的出现?

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。