数据库事务

关注公众号：CoderBuff，回复“redis”获取《Redis5.x入门教程》完整版PDF。 《Redis5.x入门教程》目录 第一章 · 准备工作 第二章 · 数据类型 第三章 · ​命令 第四章 ​· 配置 第五章 · Java客户端（上） 第六章 · 事务 第七章 · 分布式锁 第八章 · Java客户端（下） 第六章 · 事务 我们在学习MySQL的存储殷勤时知道，MySQL中innodb支持事务而myisam不支持事务。而事务具有四个特性： 一致性 原子性 隔离性 持久性 在redis尽管提供了事务相关的命令，但实际上它是一个“假事务”，因为它并不支持回滚，也就是说在redis中一个事务有多个命令执行，并不能保证原子性。所以要使用redis的事务，一定要 慎重 。 Redis中的“假事务”（不保证原子性） 在redis中事务相关的命令一共有以下几个： watch [key1] [key2] ：监视一个或多个key，在事务开始之前如果被监视的key有改动，则事务被打断。 multi ：标记一个事务的开始。 exec ：执行事务。 discard ：取消事务的执行。 unwatch ：取消监视的key。 正常执行事务 127.0.0.1:6379> multi OK 127.0.0.1:6379> set name kevin QUEUED 127.0.0.1:6379>

在SpringBoot则非常简单，只需在业务层添加事务注解(@Transactional )即可快速开启事务。虽然事务很简单，但对于数据方面是需要谨慎对待的。 @Transactional注解用于两种场景： 标于类上：表示所有方法都进行事务处理 标于方法上：仅对该方法有效 一、事务传播行为 @Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下) @Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务 @Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务 @Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常 @Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反) @Transactional(propagation=Propagation

来源： https://www.cnblogs.com/wms01/p/6183241.html 事务隔离级别（IsolationLevel） 事务的特性（ACID） 1、原子性（Atomicity） 　　事物是数据库的逻辑工作单位，事务中的诸多操作要么全做要么全不做 2、一致性（Consistency） 　　事务执行结果必须是使数据库从一个一致性状态变到另一个一致性状态 3、隔离性（Isolation） 　　一个数据的执行不能被其他事务干扰 4、持续性/永久性（Durability） 　　一个事务一旦提交，它对数据库中的数据改变是永久性的 隔离级别与并发性是互为矛盾的：隔离程度越高，数据库的并发性越差；隔离程度越低，数据库的并发性越好，这点很好理解 事务的隔离级别（IsolationLevel） 1 // 摘要: 2 // Specifies the transaction locking behavior for the connection. 3 public enum IsolationLevel 4 { 5 // 摘要: 6 // A different isolation level than the one specified is being used, but the 7 // level cannot be determined. 8 Unspecified =

今天我们来看看事务隔离的实现原理 事务隔离 隔离性与隔离级别 当数据库上有多个事务同时执行的时候，就可能出现脏读(dirty read)、不可重复读 (non-repeatable read)、幻读(phantom read)的问题，为了解决这些问题，就有 了“隔离级别”的概念 在谈隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当 出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行 在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。 在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。 在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是， “读未提交”隔离级别下直接返回记录上的最新值，没有视图概念; 而“串行化”隔离级别下直接用加锁的方式来避免并行访问 事务隔离的实现

开发老大要求通过binlog查询一条被修改的数据，数据被查出后问我，有没有可能binlog中不会记录，回答不会，因为数据被修改，若失败直接回滚，不会在binlog中记录，此刻一个朋友用了洪荒之力告诉我，失败的话也会记录，坐地无语，因为他sqlserver dba，用sqlserver的思维考虑mysql，哈哈哈哈哈，用实验让他闭嘴！ 简单测试步骤如下： root(yoon)> flush logs; Query OK, 0 rows affected (0.01 sec) root((none))> show binlog events in 'mysql-bin.000041'; +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | mysql-bin.000041 | 4 |

mysql是一种关系型数据库，关系型数据库一个重要的特性就是支持事务，这是区别于no-sql产品的一个核心特性。当然了，no-sql产品支持键值查询，不能支持sql语句，这也是一个区别。今天主要讨论下事务的提交流程，由于mysql插件式存储架构，导致开启binlog后，事务提交实质是二阶段提交，通过两阶段提交，来保证存储引擎和二进制日志的一致。本文仅讨论binlog未打卡状态下的提交流程，后续会讨论打开binlog选项后的提交逻辑。源码调试环境如下： 测试环境： OS：windows DB：mysql 5.6.12 engine：innodb 测试前置条件： set autocommit=0; create table tt(col1 int, col2 varchar(100)); 测试语句： insert into tt values(1, 'abcdef'); commit; 无论对于dml语句【insert，update，delete等】还是dcl语句【commit，rollback】，mysql提供了公共接口mysql_execute_command，我们先分析mysql_execute_command接口的基本流程： mysql_execute_command { switch (command) { case SQLCOM_INSERT: mysql_insert()

最近数据库tempdb暴涨，上网查询了相关介绍，总结如下：　　 tempdb全局存储内部对象，用户对象，临时表，临时对象，以及SQL Server操作创建的存储过程。每个数据库实例只有一个tempdb，所以可能存在性能以及磁盘空间瓶颈。各种形式的可用空间及过度饿DDL/DML操作都会导致tempdb负载过重。这会导致运行在服务器上不相干程序运行缓慢或者运行失败。 　　tempdb的一些常见通病如下： 　　--耗完了tempdb的所有存储空间 　　--读取tempdb时的I/O瓶颈造成的查询运行缓慢。 　　--过度的DDL操作造成在系统表上的瓶颈。 　　--分配竞争 　　在我们开始诊断问题之前，让我们首先看一下tempdb的空间都用在了哪些地方。可以分成四个主要的类比： 类别 描述 用户对象 这些是明确地由用户创建并且在系统类别中进行追踪。他们包括下面的： --表及索引 --全局性质的临时表（##t1）以及索引 --局部临时表（#t1）及索引 　　会话范围的 　　存储过程范围的 --表变量（@t1） 　　会话范围的 　　存储过程范围的 内部对象 SQL Server在运行查询的时候会创建或销毁许多语句范围的对象。这些 没有在系统类别中被追踪。他们包括以下内容： --工作文件（hash连接） --排序运行 --工作表（游标，池以及临时的大对象数据类型（LOB）存储） -

缓存是介于应用程序和物理数据源之间，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻或事件会同步缓存和物理数据源的数据。 　　缓存的介质一般是内存，所以读写速度很快。但如果缓存中存放的数据量非常大时，也会用硬盘作为缓存介质。缓存的实现不仅仅要考虑存储的介质，还要考虑到管理缓存的并发访问和缓存数据的生命周期。 　　Hibernate的缓存包括Session的缓存和SessionFactory的缓存，其中SessionFactory的缓存又可以分为两类：内置缓存和外置缓存。Session的缓存是内置的，不能被卸载，也被称为Hibernate的第一级缓存。SessionFactory的内置缓存和Session的缓存在实现方式上比较相似，前者是SessionFactory对象的一些集合属性包含的数据，后者是指Session的一些集合属性包含的数据。SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句，映射元数据是映射文件中数据的拷贝，而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来，SessionFactory的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义SQL语句

一级缓存和二级缓存 缓存概念 　　缓存是介于应用程序和物理数据源之间，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻或事件会同步缓存和物理数据源的数据。 　　Hibernate的缓存包括 Session的缓存和SessionFactory的缓存 ，其中SessionFactory缓存又可以分为两类：内置缓存和外置缓存。 Session缓存是内置的，不能被卸载，也被称为Hibernate的第一级缓存。 SessionFactory 的内置缓存和Session的缓存在实现方式上比较相似，前者是SessionFactory对象的一些集合属性包含的数据，后者是指Session的一 些集合属性包含的数据。SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句，映射元数据是映射文件中数据的拷贝，而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来，SessionFactory的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义SQL语句，因此SessionFactory不需要进行内置缓存与映射文件的同步。SessionFactory的外置缓存是一个可配置的插件。在默认情况下，SessionFactory不会启用这个插件

Hibernate缓存原理 : 对于Hibernate这类ORM而言,缓存显的尤为重要,它是持久层性能提升的关键.简单来讲Hibernate就是对JDBC进行封装,以实现内部状态的管理,OR关系的映射等,但随之带来的就是数据访问效率的降低,和性能的下降,而缓存就是弥补这一缺点的重要方法. 缓存就是数据库数据在内存中的临时容器,包括数据库数据在内存中的临时拷贝,它位于数据库与数据库访问层中间.ORM在查询数据时首先会根据自身的缓存管理策略,在缓存中查找相关数据,如发现所需的数据,则直接将此数据作为结果加以利用,从而避免了数据库调用性能的开销.而相对内存操作而言,数据库调用是一个代价高昂的过程. 一般来讲ORM中的缓存分为以下几类: 1: 事务级缓存 :即在当前事务范围内的数据缓存.就Hibernate来讲,事务级缓存是基于Session的生命周期实现的,每个Session内部会存在一个数据缓存,它随着 Session的创建而存在,随着Session的销毁而灭亡,因此也称为Session Level Cache. 2: 应用级缓存 :即在某个应用中或应用中某个独立数据库访问子集中的共享缓存,此缓存可由多个事务共享(数据库事务或应用事务),事务之间的缓存共享策略与应用的事务隔离机制密切相关.在Hibernate中,应用级缓存由SessionFactory实现