mysql事务

############### 视图 ############## """ 1.视图 视图:是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据 视图有如下特点; 1. 视图的列可以来自不同的表，是表的抽象和逻辑意义上建立的新关系。 2. 视图是由基本表（实表）产生的表（虚表）。 3. 视图的建立和删除不影响基本表。 4. 对视图内容的更新（添加、删除和修改）直接影响基本表。 5. 当视图来自多个基本表时，不允许添加和删除数据。 1.创建视图 create view 视图名称 as sql 查询语句 2.使用视图 select * from 视图名称; 3.更新视图 alter view 视图名称 AS SQL语句 4. 删除视图 drop view ren_view; """ ############### 触发器 ############## """ 2.触发器-trigger 触发器：监视某种情况，并触发某种操作。 触发器创建语法四要素： 1.监视地点(table) 2.监视事件(insert/update/delete) 3.触发时间(after/before) 4.触发事件(insert/update/delete) 1.创建触发器语法 create trigger triggerName after/before insert/update

事务 事务（Transaction）就是为了保证数据完整性。 特性 原子性（Atomicity，或称不可分割性）： 一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节 一致性（Consistency）： 事务必须使数据库从一个一致性状态到另外一个一致性状态，一致性和原子性是密切相关的 隔离性（Isolation，又称独立性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，一个事务不能被其它事务所干扰 持久性（Durability）：事务提交后，数据永久存在数据库中 传播属性（Propagation） 事务的传播属性是指在多个事务同时存在时，事务之间的处理关系 常 量 解释 REQUIRED 支持当前事务，如果不存在则创建新事务。类似于同名的EJB事务属性。这是事务注释的默认设置。 SUPPORTS 支持当前事务，如果不存在事务，则以非事务方式执行。 MANDATORY 支持当前事务，如果不存在则抛出异常。 REQUIRES_NEW 创建一个新事务，如果存在当前事务，则挂起它。 NOT_SUPPORTED 以非事务方式执行，如果当前事务存在，则挂起当前事务。内外事务为独立事务，互不影响 NEVER 以非事务方式执行，如果存在事务，则抛出异常。 NESTED 如果当前事务存在，则在嵌套事务中执行，否则就像REQUIRED一样

文章目录 一、掌握Mysql复制方式的区别及优缺点 二、了解半同步复制出现的必要性 半同步工作原理 三、配置半同步复制 实验环境 一、掌握Mysql复制方式的区别及优缺点 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式

MySql 中有六种日志文件：重做日志（redo log），回滚日志（undo log），二进制日志（bin log），错误日志（errlog），慢查询日志（slow query log），一般查询日志（general log），中继日志（relay log）。 这其中重做日志和回滚日志与事务操作息息相关，二进制日志与事务操作有一定关系，这篇文章我们来看看这三种日志能做什么。 重做日志（redo log） 作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，重启 mysql 服务的时候，会根据 redo log进行重做，从而达到事务的持久性这一特性。 内容：物理格式的日志，记录的是物理数据页面的修改信息，其 redo log 是顺序写入 redo log file 的物理文件中去的。 产生时间：事务开始后就产生了 redo log。在事务执行的过程中，便开始写入 redo log 文件中。 释放：当对应事务的脏页写入到磁盘之后，redo log 的使命也就完成了。 回滚日志（undo log） 作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC）。 内容：逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现。 产生时间：事务开始之前，将当前版本生成 undo

本篇文章主要介绍数据库事务的四大特性ACID，以及数据库的隔离级别。 事务 概念 事务指的是满足 ACID 特性的一系列操作。在数据库中，可以通过 Commit提交一个事务，也可以使用 Rollback 进行回滚。 四大特性 原子性（Atomicity）：事务被视为不可分割的最小单元，要么全部提交成功，要么全部失败回滚。 一致性（Consistency）：事务执行前后都保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。 隔离性（Isolation）：一个事务所做的修改在最终提交以前，对其它事务是不可见的。 持久性（Durability）：一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。可以通过数据库备份和恢复来保证持久性。 在了解完数据库的四大特性之后，我们来讨论一下数据库的隔离级别的问题。在此之前，我们考虑在没有数据库隔离性的情况下，多用户并发操作可能会发生的问题。 并发一致性问题 在并发环境下，一个事务如果受到另一个事务的影响，那么事务操作就无法满足一致性条件。 丢失修改：多个事务同时读取某一数据，一个事务成功处理好了数据，被另一个事务写回原值，造成第一个事务更新丢失。例如，T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。 脏读

MySQL作为一种关系型数据库，已被广泛应用到互联网中的诸多项目中。今天我们来讨论下事务的提交过程。 MySQL体系结构 由于mysql插件式存储架构，导致开启binlog后，事务提交实质是二阶段提交，通过两阶段提交，来保证存储引擎和二进制日志的一致。 本文仅讨论binlog未打卡状态下的提交流程，后续会讨论打开binlog选项后的提交逻辑。 测试环境 OS:WIN7 ENGINE: bin-log：off DB: 测试条件 set autocommit=0; -- ---------------------------- -- Table structure for `user` -- ---------------------------- DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(20) NOT NULL, `account` varchar(20) NOT NULL, `name` varchar(20) NOT NULL, PRIMARY KEY (`id`), KEY `id` (`id`) USING BTREE, KEY `name` (`name`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 测试语句 insert into

数据库连接 import pymysql #打开数据库连接 db = pymysql.connect('localhost','user','password','dbname') #使用cursor()方法创建一个游标对象 cursor cursor = db.cursor() #使用execute()方法执行SQL语句 cursor.execute('select version()') 使用fetchone()方法获取单条数据 data = cursor.fetchone() print('Database version : %s'%data) #关闭数据库 db.close() 创建数据库表 #如果数据库连接存在我们可以使用execute()方法来为数据库创建表，如下所示创建表EMPLOYEE： import mysql db=pymysql.connect('localhost','username','password','dbname') cursor = db.cursor() sql = """ create table employee( first_name char(20), list_name char(20), age int, sex char(1), income float )""" cursor.execute(sql) db.close()

Spring事务失效的 8 大原因，这次可以吊打面试官了！ 今天再来一篇《吊打面试官》系列，这次真的要吊打了，哈哈！（看往期吊打系列请在后台回复：吊打，我会陆续更新……） 前几天栈长不是发了一篇文章，里面有一个关于事务失效的问题： 用 Spring 的 @Transactional 注解控制事务有哪些不生效的场景？ 其中有个热心粉丝留言分享了下，我觉得总结得有点经验，给置顶了： 但是我觉得还是总结得不够全，今天栈长我再总结一下，再延着这位粉丝的总结再补充完善一下，不用说，我肯定也不见得总结全，但希望可以帮忙有需要的人。 1 数据库引擎不支持事务 这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。 根据 MySQL 的官方文档： https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html 从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是白搭。 2 没有被 Spring 管理 如下面例子所示： // @Service public class OrderServiceImpl implements OrderService {

大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 12 天，也是我第 59 次进行这种操作。 今天我温习了该专栏里一篇叫《事务隔离：为什么你改了我还看不见？》的文章。 关键词总结：隔离性与隔离级别、（隔离级别（读未提交、读提交、可重复读、串行化）、隔离级别的事务效果（读未提交、读提交、可重复读、串行化））、事务隔离的实现、事务的启动方式（显式启动、隐式启动）。 所学总结： 《事务隔离：为什么你改了我还看不见？》 隔离性与隔离级别 解决脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）等问题。 隔离级别 读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）以及串行化（serializable）。 读未提交 事务提交之前其所做的变更可被其他事务看见。 读提交 事务提交之后其所做的变更才可被其他事务看见。 可重复读 事务执行过程看到的数据总是和事务在启动时看到的数据一致。事务提交之前其所做的变更对其他事务不可见。 串行化 对于同一条记录，写时加写锁，读时加读锁。出现读写锁冲突时需要等事务执行完成才能继续。 隔离级别的事务效果 读未提交 虽然事务 B 还未提交，但事务 A 能看到其结果。 读提交 事务 B

数据库锁 共享锁(Shared lock) 例1： ---------------------------------------- T1: select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象） T2: update table set column1='hello' 过程：T1运行 （加共享锁) T2运行等待T1运行完之后再运行T2 之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1执行完，释放了共享锁，才能加上排他锁，然后才能开始执行update语句。 例2： ---------------------------------------- T1: select * from table T2: select * from table 这里T2不用等待T1执行完，而是可以马上执行。 分析： T1运行，则table被加锁，比如叫lockA T2运行，再对table加一个共享锁，比如叫lockB。 两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻止其它session update 例3： ---------------------------------