mysql事务

目录 联合分组 子查询 all与any 视图：view 视图的增删改 事务 pymysql：python操作mysql 安装 增删改查 创建表 增 删 改 查 游标操作 pymysql事务 sql注入 索引 联合分组 # 数据来源：在单表emp下 # 联合分组：按多个字段综合结果进行分组 # 按 area与port 组合后的结果进行分组，只有组合后的结果还一致，才认为是一组 select group_concat(name),area,port from emp group by area,port; 子查询 # 增：insert into 表 select子查询 # 删：delete from 表 条件是select子查询(表不能与delete表相同) # 改：select 字段 from 表 条件是select子查询 # 查：update 表 set 条件是select子查询(表不能与delete表相同) # 数据来源：在单表emp下 # 子查询：将一条查询saql的结果作为另一条sql的条件 # 思考：每个部门最高薪资的那个人所有信息 # 子查询的sql select dep,max(salary) from emp group by dep; # 子查询 - 查 select * from emp where(dep,salary) in (select dep,max

事务 # 事务：通常一些业务需要多条sql参与，参与的sql会形参一个执行整体，该整体我们就称之为 事务 # 简而言之：事务 - 就是保护多条执行的sql语句 # 比如：转账就是一个事务：从一个用户将资金转出，再将资金转入到另一个用户 """ 事务的四大特性 1.原子性：事务是一组不可分割的单位,要么同时成功,要么同时不成功 2.一致性：事物前后的数据完整性应该保持一致(数据库的完整性：如果数据库在某一时间点下，所有的数据都符合所有的约束，则称数据库为完整性的状态) 3.隔离性：事物的隔离性是指多个用户并发访问数据时，一个用户的事物不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离 4.持久性：持久性是指一个事物一旦被提交，它对数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响 """ # mysql中事务的执行 create table bank( id int, name varchar(16), money decimal(65, 2) ); insert into bank values(1, 'Tom', 10), (2, "Bob", 10); # 假设出现以下执行情况 # 没有事务支持情况下，Tom的钱就丢了 update bank set money=money-1 where name='Tom'; update bank set

简介 每一个SQL Server的数据库都会按照其修改数据(insert,update,delete)的顺序将对应的日志记录到日志文件.SQL Server使用了Write-Ahead logging技术来保证了事务日志的原子性和持久性.而这项技术不仅仅保证了ACID中的原子性(A)和持久性(D),还大大减少了IO操作，把对数据的修改提交到磁盘的工作交给lazy-writer和checkpoint.本文主要讲述了SQL Server修改数据时的过程以及相关的技术。 预写式日志（Write-Ahead Logging (WAL)） SQL Server使用了WAL来确保了事务的原子性和持久性.实际上，不光是SQL Server,基本上主流的关系数据库包括oracle,mysql,db2都使用了WAL技术. WAL的核心思想是: 在数据写入到数据库之前，先写入到日志. 因为对于数据的每笔修改都记录在日志中，所以将对于数据的修改实时写入到磁盘并没有太大意义，即使 当SQL Server发生意外崩溃时，在恢复(recovery)过程中那些不该写入已经写入到磁盘的数据会被回滚(RollBack),而那些应该写入磁盘却没有写入的数据会被重做(Redo)。从而保证了持久性(Durability) 但WAL不仅仅是保证了原子性和持久性。还会提高性能. 硬盘是通过旋转来读取数据,通过WAL技术

接上一篇： spring学习笔记(十二)：使用 xml 方式实现 spring 的声明式事务管理（使用对 jdbc 的支持） 实体类 Dept.java： public class Dept { private int deptId; private String deptName; public int getDeptId() { return deptId; } public void setDeptId(int deptId) { this.deptId = deptId; } public String getDeptName() { return deptName; } public void setDeptName(String deptName) { this.deptName = deptName; } @Override public String toString() { return "Dept{" + "deptId=" + deptId + ", deptName='" + deptName + '\'' + '}'; } } DeptDao.java： @Component // 加入 IOC 容器 public class DeptDao { @Resource // IOC 容器注入 private JdbcTemplate jdbcTemplate

声明： 本篇主要对所用到的技术做了归纳总结，对源码讲解较少，如果有基础的朋友可以直接下载源码结合时序图更能容易理解；基础比较弱的朋友建议先看看资料自看源码这样更容易理解。这里的部分资料来源于网络，所以这里对那些资料提供者表达衷心的感谢。 方案： 业务流程：Tss库向Saas转移库存，order为记录表。 技术栈： Springboot+mysql+postgreSQL+atomikos+mybatis 项目代码地址：https://github.com/bao17634/springboot-kafka-demo.git 1、分布式事务模型 ACID 实现 1.1、X/Open XA 协议（XA） 最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing(DTP)模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。 DTP模型如图： TM：全局事务管理器 RM：多个资源管理器 AP：应用程序 全局事务管理器负责管理全局事务状态与参与的资源，协同资源一起提交或回滚;资源管理器则负责具体的资源操作。 XA 协议主要描述了 TM 与 RM 之间的接口，允许多个资源在同一分布式事务中访问。 基于 DTP 模型的分布式事务流程大致如下： XA接口详解 XA接口时双向的系统接口

redo log漫游 redo log -> 物理日志 redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。 redo log是InnoDB引擎独有的 redo log包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。redo log在数据准备修改前写入缓存中的redo log中，然后才对缓存中的数据执行修改操作；而且保证在发出事务提交指令时，先将缓存中的redo log写入日志，写入完成后才执行提交动作。 redo log的写入是使用了WAL（Write-Ahead Logging）技术。 redo log 记录的是物理页的情况，具有幂等性，因此记录的日志极其简练。 WAL：用户如果对数据库中的数据进行了修改，必须保证日志先于数据落盘。当日志落盘后，就可以给用户返回操作成功，并不需要保证当时对数据的修改也落盘。如果数据库在日志落盘前crash，那么相应的数据修改会回滚。在日志落盘后crash，会保证相应的修改不丢失。 日志刷入磁盘 为了确保每次日志都能写入到事务日志文件中，在每次将log buffer中的日志写入日志文件中的过程中

编程式事务管理： 自己手动控制事务，就叫做 编程式事务管理。 编程式事务管理可以清楚的定义事务的边界，可以实现细粒度的事务控制，比如可以通过代码控制事务何时开始，何时结束。 例如 jdbc、hibernate 就是编程式事务管理，spring 中不提倡使用。 jdbc 代码： conn.setAutoCommite(false); // 设置 手动控制事务 hibernate 代码： session.beginTransaction(); // 开启一个事务 细粒度 的事务控制：可以对指定的方法、或指定方法的某几行添加事务控制； 比较灵活，但开发起来比较繁琐，每次都要开启、提交、回滚。 声明式事务管理： 如果不需要细粒度的事务控制，可以使用声明式事务。 spring 中提供的对事务的管理，就叫做声明式事务管理。 只需要在 spring 配置文件中做一些配置，即可将操作纳入到事务管理中，解除了和代码的耦合。 spring 声明式事务管理，核心实现就是基于 AOP。 Spring 声明式事务管理器类： Jdbc 技术： DataSourceTransactionManager Hibernate 技术： HibernateTransactionManager 使用 xml 方式实现 spring 的声明式事务管理 需要引入 aop 名称空间 和 tx 名称空间。 DeptDao

本文将按照声明式事务的五个特性进行介绍： 事务传播机制 事务隔离机制 只读 事务超时 回滚规则 Spring事务传播机制 事务的特性 原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。 一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。 隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。 持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。 Spring事务的配置方式 Spring支持编程式事务管理以及声明式事务管理两种方式。 1. 编程式事务管理 编程式事务管理是侵入性事务管理，使用TransactionTemplate或者直接使用PlatformTransactionManager，对于编程式事务管理，Spring推荐使用TransactionTemplate。 2. 声明式事务管理 声明式事务管理建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务

#TCL语言 /* transaction control language事务控制语言 事务： 一个或者一组SQL语句组成一个执行单元，这个执行单元要么全部执行，要么全部不执行 案例：转账，张三丰向郭襄转账500 张三丰 1000 郭襄 1000 update 表 set 张三丰的余额=500 where name="张三丰" 再上面执行完之后，数据库挂了，咋解决：这里面涉及事物机制 update 表 set 郭襄的余额=1500 where name="郭襄" 整个单独单元作为一个不可分割的获赠提，如果单元中某条sql语句一旦执行失败或者产合适呢个错误， 整个单元将会回滚（撤销之前的所有操作）。所有受到影响的数据将返回到事物开始前的状态；如果单元中的所有sql语句均执行成功，则事物被顺利执行。 存储引擎：在mysql中的数据用各种不同的技术存储在文件（内存）中。 show engines; 事物的ACID属性 1.原子性atomicity:事务：不可再分的工作单元 2.一致性consistency:一个状态转为另外一状态的总和时不变的 3.隔离性isolation:事务之间应该时隔离的（但是需要看隔离级别） 4.持久性durability:事务一旦被提交，就是永久性的 事务的创建 隐式事务：事务没有明显的开启和结束的标记 比如insert,update,delete语句

Q：为什么要用锁？什么样的业务场景下需要用锁？ 就拿之前的工单系统来说，当审批方式为角色组审批时，代表该角色组内任意一人审批即可，这时，该角色组内成员的系统上都是可以显示审批按钮，如果此时A审批员和B审批员都同时审批了同一工单，有可能会出现不一样的审批结果，即使审批意见是一致的，多人操作也会增加对数据库的操作次数，同时也消耗了很大时间成本，用了锁机制，确保这部分是只一人在操作。 Q：你知道MySQL有哪些锁？ 悲观锁、乐观锁 排它锁、共享锁 行级锁、表级锁 悲观锁：对每次访问数据库的操作都是抱有悲观的态度，认为该操作会对数据库做出修改，所以在访问数据库的时候就加了锁 乐观锁：对每次访问数据库的操作都抱有乐观的态度，只有在做出修改的时候才会上锁 排它锁：也称为写锁，若事务A对数据A上了写锁，那么此时只允许事务A对数据A进行读和写的操作，不允许数据A再接受其他的锁，直到排它锁释放之后 共享锁：也称为读锁，若事务A对数据A上了读锁，那么此时事务A只能读取数据A并不能对其修改，也能接受其他事务对数据A的读锁 mysql数据库引擎：MyISAM 和 InnoDB MyISAM 采用表级锁，不支持事务 InnoDB 默认行级锁，也支持表级锁 行级锁：如根据主键id字段进行查找，并且查找到数据，主键字段就产生了行级锁 表级锁：根据非主键非索引字段进行查找，并且查找到数据，当前查找字段产生表级锁