mysql事务

视图 视图概念 视图是存储的查询语句,当调用的时候,产生结果集,视图充当的是虚拟表的角色。其实视图可以理解为一个表或多个表中导出来的表，作用和真实表一样，包含一系列带有行和列的数据 视图中，用户可以使用SELECT语句查询数据，也可以使用INSERT，UPDATE，DELETE修改记录，视图可以使用户操作方便，并保障数据库系统安全，如果原表改名或者删除则视图也失效。 视图操作 创建视图 语法结构： CREATE [ OR REPLACE ] VIEW [ view_name ] AS [ SELECT_STATEMENT ] ; 释义： CREATE VIEW ： 创建视图 OR REPLACE : 可选，如果添加原来有同名视图的情况下会覆盖掉原有视图 view_name ： 视图名称 SELECT_STATEMENT ： SELECT 语句 e . g . create view c1 as select name , age from class_1 ; 视图表的增删改查操作 视图的增删改查操作与一般表的操作相同，使用insert update delete select即可，但是原数据表的约束条件仍然对视图产生作用。 删除视图 drop view [IF EXISTS] 视图名； IF EXISTS 表示如果存在，这样即使没有指定视图也不会报错。 drop view c1 ;

摘自：https://www.cnblogs.com/protected/p/6526857.html 关于数据库的各种锁的总结： 1.共享锁（又称读锁）、排它锁（又称写锁）： InnoDB引擎的锁机制： InnoDB支持事务，支持行锁和表锁用的比较多，Myisam不支持事务，只支持表锁。 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。 排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。 意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。 意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。 说明： 1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。 2）对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。 共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 排他锁（X)：SELECT * FROM table_name

在默认情况下，在innodb存储引擎的数据目录下会有两个名为ib_logfile0和ib_logfile1的文件。在MYSQL官方手册中将其称为innodb存储引擎的日志文件，不过准确的定义应该是重做日志文件（redo log file）. 当实例或介质失败时，重做日志文件就能派上用场。例如，数据库由于所在主机掉电导致实例失败，innodb存储引擎会使用重做日志回复到掉电前的时刻，以此来保证数据的完整性。 每个innodb存储引擎至少有一个重做日志文件组（group）,每个文件组下至少有两个重做日志文件，如默认的ib_logfile0和ib_logfile1.为了得到更高的可靠性，用户可以设置多个的镜像日志组（mirrored log groups）将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行。innodb存储引擎先写重做日志文件1，当达到文件的最后时，会切换至重做日志文件2，再当冲走日志文件2也被写满时，会再切换到重做日志文件1中。如图: 下列参数影响着重做日志文件的属性： innodb_log_file_size ---每个重做日志文件的大小 innodb_log_files_in_group --日志组中重做日志文件的数量 innodb_mirrored_log_groups ----5

Mysql锁技术详解 本文只讨论InoDB存储引擎下的锁。 前言 在分布式并发的场景下，对于共享资源的操作是非原子性的，这会造成操作和预期的结果并不一致。 原子性操作 ：指在一次CPU的调度时间类完成的一系列操作，顺序不可打乱，也不可只执行一部分。 任何可能能被CPU打断的操作都不是原子操作，所以真正的原子操作需要硬件支持，但是硬件大多数只支持系统的核心方法的原子操作，所以如果想要在自己开发的程序里做原子操作，需要引入锁。在线程A操作共享资源时需要拿到锁，这样即便线程A的操作中途CPU切换到了线程B，线程B想要读取共享资源时缺拿不到锁，所以线程B无法操作共享资源，这样就模拟出了原子操作，保证了线程A的逻辑是完整正确的。 MySQL的事务具有原子性，所以MySQL肯定实现了许多锁来保证原子操作。以InoDB为例，来看看MySQL实现了哪些锁，这些锁又分别有什么作用。 根据锁的范围来分类，大致分为了三类锁： 全局锁 表锁 行锁 全局锁 顾名思义，全局锁就是对整个数据库实例都加上锁，命令行是 Flush tables with read lock，一旦数据库加上此锁，除了当前操作线程之外，其他的线程对数据库的增删改操作都会被阻塞，包括建表，修改表结构事务更新等操作。 全局锁一般用于数据备份，为了保证备份的一致性，加上全局锁确保备份时间类数据库里的数据不会有更新。

1. 隔离级别 (1) 读不提交 (Read Uncommited ， RU) 这种隔离级别下，事务间完全不隔离，会产生脏读，可以读取未提交的记录，实际情况下不会使用。 (2) 读提交 (Read commited ， RC) 仅能读取到已提交的记录，这种隔离级别下，会存在幻读现象，所谓幻读是指在同一个事务中，多次执行同一个查询，返回的记录不完全相同的现象。幻读产生的根本原因是，在 RC 隔离级别下，每条语句都会读取已提交事务的更新，若两次查询之间有其他事务提交，则会导致两次查询结果不一致。虽然如此，读提交隔离级别在生产环境中使用很广泛。 (3) 可重复读 (Repeatable Read, RR) 可重复读隔离级别解决了不可重复读的问题，但依然没有解决幻读的问题。那么不可重复读与幻读有什么区别呢？不可重复读重点在修改，即读取过的数据，两次读的值不一样；而幻读则侧重于记录数目变化【插入和删除】。一般教科书上告诉我们只有到串行化隔离级别才解决幻读问题，但mysql的innodb比较特殊，RR即解决了幻读问题，主要通过GAP锁实现。另外， 不是所有的数据库都实现了该隔离级别，后面会简单介绍下 mysql 是如何实现可重复读隔离级别的。 (4) 串行化 (Serializable) 在串行化隔离模式下，消除了脏读，幻象，但事务并发度急剧下降，事务的隔离级别与事务的并发度成反比

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 掌握了JDBC最基本的与数据库交互后，接下来，我们要修炼进阶篇了，此篇涉及大量的专业名词，需要有一定天赋的修行者修炼，不过，我相信，能够轻松通过第一篇的你，绝对是那个骨骼精奇，天资聪慧的修行者~那么，我们进入此次的修行把---JDBC的事务管理 事务：在一个业务场景中，保持一系列操作的整体性，我们称作事务~简单来讲，在一系列的操作中，要么，所有操作都生效，要么所有操作都不生效，不存在某些操作生效，某些操作不生效的情况。举个例子~业务场景：小鱼儿转10定金子给花无缺；涉及的操作：1.钱从小鱼儿的兜里转出~2.钱转入到花无缺的兜中~，两个操作缺一不可，如果操作1在途中受阻，那么钱就会回到小鱼儿的兜中，只有这样，才能保证我业务操作的完整性。 事务的特性： 1、原子性（atomicity）：组成事务的语句形成了一个逻辑单元，不能只执行一部分； 2、一致性（consistency）：在事务处理执行前后，数据库与理论值是一致的（数据库完整性约束）； 3、隔离性（isolcation）：一个事务处理和另一个事务处理相互间互不影响； 4、持续性（durability）：事务处理的效果能够被永久保存下来。 隔离级别： 1、多线程并发执行可能会产生以下三个问题： 　　脏读（dirtyreads）

四种隔离级 1,read uncommitted(读取未提交内容) 在read uncommitted隔离级，所有事务都可以“看到”未提交事务的执行结果。在这种级别上，可能会产生很多问题，除非用户真的知道自己在做什么，并且很多的理由选择这样做。本隔离级别很少用于实际应用，因为它的性能也不必其他级别好多少，而别地级别还有其他更多的优点。读取未提交数据，也被称之为脏读(dirty read)。 2,read committed(读取提交内容) 大多数数据库系统的默认隔离级别为read committed（但不是mysql默认的）。它满足了隔离级别早先简单定义：一个事务在开始时，只能”看见“已经提交事务所做得改变，一个事务从开始到提交前，所做得任何数据改变都是不可见的，除非已经提交。这种隔离级别也支持 所谓的”不可重复读(nonrepeatable)“,意味着用户运行同一语句两次，看到的结果是不同的。 3,repeatable read(可重读) repeatable read隔离级解决了read uncommitted隔离级导致的问题。它却确保同一事务的多个实例在并发读取数据时，会”看到同样地“数据行。不过理论上，这会导致另外一个棘手的问题，幻读(phantom read)。简单来说，幻读指当用户读取某一个范围的数据行时，另外一个事务又在该范围内插入插入了心行

前言： 我一直想不到一个好的标题应该怎么写。我想MySQL的一些重要的内容。我在两次面试中都遇到过的，但直接用MySQL标题好像又不太贴切。干脆就是所写的内容吧。 MySQL事务： transaction Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. Database transactions, as implemented by InnoDB , have properties that are collectively known by the acronym ACID, for atomicity, consistency, isolation, and durability. See Also ACID , commit , isolation level , lock , rollback

原文: MySQL 架构 MySQL架构和结构分析 官方架构图： MySQL DB 各模块架构图如下： MySQL安装方式 MySQL初始化 简介：什么是事务； 事务： ACID ： 事务确保了银行不会弄丢你的钱，而这种特性在应用逻辑设计中是很难实现的，甚至不可实现。一个ACID兼容的数据库服务器，要为事务处理大量的复杂工作确保ACID特性的实现，而这也许是用户未能察觉到的。 事务： ACID ： A ：原子性(Atomicity) ： 一个事务必须被视为一个单独的内部”不可分“的工作单元，以确保整个事务要么全部执行，要么全部回滚。当一个事务具有原子性时,该事务绝对不会被部分执行,要么完全执行，要么根本就不执行。 C：一致性 (consistency)： 数据库总是从一种一致性状态转换到另一种一致性状态。只要是最终事务没有被提交，任何事务处理过程中所做的数据改变，也不会影响到数据库的内容。 I：隔离性 (leolation) ： 某个事务的结 果只有在完成之后才对其它事务可见 D：持久性(durability) ： 一旦一 个事务提交，事务所做的数据改变是永久的。这意味着数据改变已被记录，即使系统崩溃，数据也不会因此丢失，持久性是个有点模糊的概念，因为实际上持久性也分为很多级别。 隔离： 隔离级别 read uncommitted ： 读 未提交内容：在read

Fescar是阿里18年开源的分布式事务的框架。Fescar的开源对分布式事务框架领域影响很大。作为开源大户，Fescar来自阿里的GTS，经历了好几次双十一的考验，一经开源便颇受关注。今天就来看了Fescar的代码，看看到底是怎么一回事。 Fescar与XA两阶段提交 在XA协议中分为两阶段: 第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交. 第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。 优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。 缺点 1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题） 3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求