mysql事务

一、关于事务的隔离级别： sql定义四种隔离级别（由低到高） 1 Read Uncommitted 读取未提交内容 2 Read Committed 读取提交内容 3 Repeatable Read 可重读 4 Serializable 可串行化 二、不同隔离级别所面对的问题 四种隔离级别通过不同的锁类型实现，在读取同一个数据，就容易发生问题。 问题有三种 ：脏读，不可重复读，幻读。 不同的隔离级别可能产生的问题也不同 隔离级别 脏读 不可重复读 幻读 Read Uncommitted √ √ √ Read Committed × √ √ Repeatable Read × × √ Serializable × × × 三、产生问题的原因 脏读：首先有行记录a，事务A将记录a修改为a1，但尚未提交（可能会提交失败）。事务B读取到了未提交的数据a1。 原因：因为一旦事务A回滚，那么事务B读取到的a1就是无效数据。 不可重复读：同一事务对一条记录读取2次，得到的结果不一致。 原因：两次读取的过程中，事务B对这条记录进行了修改。 幻读：事务A 读取一条where子句的结果集，2次读取得到的记录多出n条。 原因：两次读取过程中，事务B对数据库插入新行，并且满足事物A的where 条件。 oracle数据库 只支持Read Committed 和 Serializable，默认第二种;

一.锁 mysql中的加锁，不会防止其他用户的查询，会防止其他用户的增删改操作。 entries = Entry.objects.select_for_update().filter(author=request.user) #所有匹配的行将被锁定，直到事务结束 select_for_update(nowait=False, skip_locked=False) #注意必须用在事务里面 目前，postgresql，oracle和mysql数据库后端支持select_for_update()。 但是，MySQL不支持nowait和skip_locked参数。 二.事务 1.全局开启 当有请求过来时，Django会在调用视图方法前开启一个事务。如果请求正确处理并正确返回了结果，Django就会提交该事务。否则，Django会回滚该事务。 这个功能使用起来非常简单，你只需要将它的配置项 ATOMIC_REQUESTS 设置为True。 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'mxshop', 'HOST': '127.0.0.1', 'PORT': '3306', 'USER': 'root', 'PASSWORD': '123', 'OPTIONS': { "init

一.项目架构 注：删除了原有的数据库工具，添加了c3p0数据库工具类，添加了c3p0的配置文件，修改了Dao类以及servlet类 二.修改或添加的类 1.C3p0Helper（暂时不了解事务回滚之类的怎么用或者有什么用，只用了连接和关闭） package helper; import java.sql.Connection; import java.sql.SQLException; import javax.sql.DataSource; import com.mchange.v2.c3p0.ComboPooledDataSource; public class C3p0Helper { private static String configName = "mysql"; //如果无参，则使用c3p0-config.xml中的default-config,该处使用mysql的配置 private static DataSource ds = new ComboPooledDataSource(configName); /** * 它为null表示没有事务 * 它不为null表示有事务 * 当开启事务时，需要给它赋值 * 当结束事务时，需要给它赋值为null * 并且在开启事务时，让dao的多个方法共享这个Connection */ private static

1.事务特性ACID 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持续性（Durability） 2.事务隔离级别 读未提交（Read Uncommited）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable） 3.可能出现问题表格 ------------------------- 脏读 不可重复读 幻读 RU true true true RC false true true RR false false true S false false false ------------------------- 4.RU和S在实际应用中基本不用，RU会导致脏读，数据不可置信。S锁级别太高，性能差 5.Mysql默认隔离级别为RR，Oracle等其他默认级别为RC，Mysql推荐binlog格式为row 6.Mysql默认级别为RR的原因是，在Mysql早期，binlog只有statement格式，对于master/slave主从复制可能出现顺序错误的bug 后期Mysql推出了row级别日志解决了此问题，所以所有业务型数据库推荐隔离级别为RC 7.推荐隔离级别为RC的原因（RC优于RR的原因） -RC比RR更不容易出现死锁 -在索引未达成的情况下，RR锁全表

MySQL的四种事务隔离级别 一:事务的基本要素 原子性(Atomic):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节.事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样. 一致性(consistent):事务开始前和结束后,数据库的完整性约束没有被破坏.比如A向B转账,不可能A扣了钱,B却没有收到. 隔离性(isolation):同一时间,只允许一个事务请求同意数据,不同事务之间彼此没有任何干扰.比如A正在从一张银行卡取钱,在A取钱的过程结束前,B不能 持久性(durable):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚. 二:事务的并发问题 脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据 不可重复读:事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据做了更新并提交,导致事务A多次读取同一个数据时,结果不一致 幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改完分数结束后发现还有一条记录没有改过来,就好像发生了幻觉一样. 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 三

package com.hope.service.impl;import com.hope.dao.IAccountDao;import com.hope.domain.Account;import com.hope.service.IAccountService;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import org.springframework.transaction.annotation.Propagation;import org.springframework.transaction.annotation.Transactional;/** * @author newcityman * @date 2019/11/20 - 16:45 */@Service("accountService")@Transactional(readOnly = true,propagation = Propagation.SUPPORTS)public class AccountServiceImpl implements IAccountService { @Autowired private

一. 乐观锁 乐观锁并不是真实存在的锁，而是在更新的时候判断此时的库存是否是之前查询出的库存，如果相同，表示没人修改，可以更新库存，否则表示别人抢过资源，不再执行库存更新。类似如下操作。 # sql实现语句update tb_apple set stock=2 where id=1 and stock=7;# djano中ORM实现语句 apple.objects.filter(id=1, stock=7).update(stock=2) 二.乐观锁下单逻辑 第一步 : 下单逻辑 def create(self, validated_data): """ 保存订单 """ # 获取当前下单用户 user = self.context['request'].user # 组织订单编号 20170903153611+user.id # timezone.now() -> datetime order_id = timezone.now().strftime('%Y%m%d%H%M%S') + ('%09d' % user.id) address = validated_data['address'] pay_method = validated_data['pay_method'] # 生成订单 with transaction.atomic(): # 创建一个保存点 save_id

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"> <!--配置业务层--> <bean

3. 分布式事务解决方案之2PC（两阶段提交） 针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。 3.1. 什么是2PC 2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两阶段，P是指准备阶段，C是提交阶段。 举例 ：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊肿羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成两尴尬的一幕 ： 准备阶段 ：老板要求张三付款，张三付款。老板要求李四付款，李四付款。 提交阶段 ：老板出票，两人拿票纷纷落座就餐。 例子中形成两一个事务，若张三或李四其中一个拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。 整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。 在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议，如下图 ： 1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务

1、MySQL 命令行客户端命令 mysql -u root -p (创建用户时候用这个登录) Enter the password: show databases;-- 查看数据库 show tables; -- 查看表 use test; --使用test数据库 SQL Structured Query Language 结构化查询语言（所有数据库通用，不同的是，不同数据库有不同的函数）； 2、数据定义语音（DDL） Data Definition Language 如create 创建drop删除 alter修改 对表结构的修改就是数据定义语言 （ 是表一级的 ） create database dname; create table teacher( tid int(11) primary key auto_increment COMMENT '老师编号 ', name varchar(20) COMMENT '老师姓名 ', gender char(1) COMMENT '老师性别 ', age int(2) COMMENT '老师年龄 ', birth date COMMENT '老师生日' ); desc tname;查看表结构 属性之间用 空格隔开 drop table; 注明：COMMENT 是对表字段的描述的一个字段属性 修改表 alter table 表名