mysql事务

read-uncommitted（未提交读） 测试流程： 1、A设置read-uncommitted, start transaction 2、B执行start transaction，修改一条记录， 3、A查询记录，得到了以为正确的记录 4、B回滚。 问题：A读到了B没有提交的记录，也就是脏读。 read-committed（已提交读） 测试流程： 1、A设置read-committed, start transaction 2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功 3、A查询记录，结果还是老的记录 4、B提交事务 5、A再次查询记录，结果是新的记录。 问题：解决了脏读的问题，但是出现一个新问题，A在一个事务中，两次读取的记录不一致，也就是不可重复读。 repeatable-read（可重复读） 测试流程： 1、A设置repeatable-read, start transaction，查询记录，结果是老的记录 2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功 3、A查询记录，结果还是老的记录 4、B提交事务 5、A再次查询记录，结果还是老的记录。 问题：可以重复读，A在事务过程中，即使B修改了数据，并且commit，A读取的还是老的数据。实际上是A读取的数据还是事务开始时的快照。 注意

背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性；如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？因此简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现。 二、隔离性与隔离级别

1、锁的类型分为读锁和写锁，这个很好区分。可以这样认为：如果有增删改，就是写锁。如果是查询，就是读锁。 2、锁的粒度也就是锁的范围，分为行锁和表锁。锁的范围和多个因素有关，包括事务隔离级别、是否使用索引。 测试 read-committed，结果是行锁 事务A: mysql> select @@session.tx_isolation; +------------------------+ | @@session.tx_isolation | +------------------------+ | READ-COMMITTED | +------------------------+ 1 row in set (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> update test set num=num+1 where id=1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 事务B: mysql> select @@session.tx_isolation; +------------------------+ | @@session.tx_isolation |

JVM面试题集 1.说一说类加载的详细过程。 答：类加载器加载类到JVM中，分为以下几个步骤： 1）加载：查找并加载类的二进制数据，同时在Java堆中也创建一个java.lang.class类的对象。 2）连接：连接又包含三块内容（验证、准备、初始化） a.验证：文件格式、元数据、字节码、符号引用验证。 b.准备：为类的静态变量分配内存，并将其初始化为默认值。 c.解析：把类中的符号引用转换为直接引用。 3）初始化：为类的静态变量赋予正确的初始值。 补充：Java的执行机制 先编译后运行→先编译后解释执行→解释又分为解析和加载 2.类加载完以后JVM干了什么？ 答：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。 3.讲一讲什么情况下会出现内存溢出和内存泄漏。 答：内存溢出的原因 1）内存泄漏导致堆栈内存不断增大，从而引发内存溢出。 2）大量的jar、class文件加载，装载类的空间不够，从而溢出。 3）nio直接操作内存，内存过大导致溢出。 解决： 1）查看程序是否存在内存泄漏的问题。 2）设置参数加大空间。 3）代码中是否存在死循环或者循环产生过多重复的实例。 4）查看是否使用了nio直接操作内存。 4.简述Java内存模型以及分区，需详细到每个区放什么？ 答：JVM分为堆区、栈区和方法区，初始化的对象放在堆里面，引用放在栈里面，class类信息

一、 1、 #事务 一个或一组SQL要么全部执行，要么全部不执行 #事务的ACID属性 #原子性（Atomicity） 一个事务是一个整体 不可拆分 要么都成功 要么都失败 #一致性（Consistency） 事务必须使数据库从一个一致性状态，变换到另一个一致性状态 也就是本来两个人金额总和为200，转账后也得是200 #隔离性（Isolation） 两个事务相互隔离，并发执行的各个事务不能相互干扰 #持久性（Durability） 一个事务一但被提交，它对数据库中的数据的改变是永久性的 事务的ACID属性 #start transaction; 开启事务 update user set balance = balance-100 where name = 'hby'; update user set balance = balance-100 where name = 'pdun'; #rollback; #全部撤销（回滚） #commit; 注意：commit前可以回滚，一旦执行了commit，将无法回滚 ------------------------------------------------------------------------ #start transaction; update user set balance = balance-100 where

Transaction 把所有事情当一件事做–>原子性 事务有缓存 事务只有提交（commit）后，才会改了数据–>mysql命令行界面可以 begin; ...sql语句 commit; 未提交前可以回滚（rollback） begin; ...sql语句 rollback; commit; 可以在存储过程中写事务 delimiter $$ create procedure pro_traction_transfer_money(in fname varchar(255),in tname varchar(255),in account int,out res varchar(255)) begin declare balance double default 0; start transaction; update user set money=money-account where name=fname; select money into balance from user where name=fname; if balance>=0 then update user set money=money+account where name=tname; commit; set res='转账成功'; else rollback; set res='余额不足'; end if

在数据库的锁机制中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以， 不 要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈 。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 一、悲观锁 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 悲观锁，正如其名，它指的是对数据被外界

Django中事物的使用 from django.db import transaction @transaction.atomic 通过transaction的@transaction.atomic装饰器来开启事务，在视图逻辑涉及数据库操作的地方添加事物保存点，在操作不满足时进行事物回滚，在操作满足是进行事物提交 # 前端传递的参数:地址id(addr_id) 支付方式(pay_method) 用户要购买的商品id字符串(sku_ids) # mysql事务: 一组sql操作，要么都成功，要么都失败 # 高并发:秒杀 # 支付宝支付 class OrderCommitView(View): '''订单创建''' @transaction.atomic def post(self, request): '''订单创建''' # 判断用户是否登录 user = request.user if not user.is_authenticated(): # 用户未登录 return JsonResponse({'res': 0, 'errmsg': '用户未登录'}) # 接收参数 addr_id = request.POST.get('addr_id') pay_method = request.POST.get('pay_method') sku_ids = request.POST

1 简介 就是全局事务ID(global transaction identifier ) 属于全局唯一 2 构成 uuid+transaction_id 3 格式 7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1-N binlog SET @@SESSION.GTID_NEXT= '' 4 概念和变量解读 1 Previous-GTIDs 可以看出,每个binlog开头都记录着从GTID开启到这个binlog之前的binlog文件GTID执行事务的总和,即便不开启GTID,也会记录 2 gtid_executed表 1 状态:不可以手动更改 2 内容:已经执行过的事务GTID总和,RESET MASTER会清空此值 3 mysql5.6记录在内存中,所以需要开启中继日志记录进行持久化(GTID_LOG_EVENT) mysql5.7 为一个innodb_table实现持久化 从库就不需要开启中级日志了 4 触发更改内容(适用于gtid_executed gtid_purged变量) 1 set global gtid_purged='' 常见于搭建从库 2 reset master 清空 executed表 3 gtid_purged 状态:可以手动更改 内容:已经被删除的binlog的事务GTID,它是GTID_EXECUTED的子集 4 gtid

重要概念 自动提交模式 对于mysql数据库，默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。对于正常的事务管理，是一组相关的操作处于一个事务之中，因此必须关闭数据库的自动提交模式，下面是查看方式： 查看是否自动提交命令（ON表示开启自动提交，值为1，OFF表示关闭自动提交，值为0）： show variables like 'autocommit'; 关闭自动提交后，则用户将一直处于某个事务中，直到执行一条commit提交或rollback语句才会结束当前事务重新开始一个新的事务。 DataSource connection = masterDataSource.getConnection(); connection.setAutoCommit(false); 事务隔离级别 隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量： TransactionDefinition.ISOLATION_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。