数据库事务

微信公众号【黄小斜】大厂程序员，互联网行业新知，终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」 等关键字可以获取对应的免费学习资料。 ​ 事务的概念 事务指逻辑上的一组操作，组成这组操作的各个单元，要不全部成功，要不全部不成功。 例如：A向B转账100元，对应于如下两条sql语句： update from account set money=money+100 where name='b'; update from account set money=money-100 where name='a'; 1 2 1 2 数据库 默认事务是自动提交的，也就是发一条sql它就执行一条，如果想多条sql放在一个事务中执行，则需要使用如下语句： start transaction … … commit 1 2 3 4 1 2 3 4 数据库开启事务命令： start transaction ：开启事务 rollback ：回滚事务 commit ：提交事务 MySQL数据库中操作事务命令 编写 测试 SQL脚本，如下： /* 创建数据库 */ create database day16

幻读 幻读是指当事务不是独立执行时发生的一种现象。 事务A读取与搜索条件相匹配的若干行。事务B以插入或删除行等方式来修改事务A的结果集，然后再提交。 幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的“全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行，就好象发生了幻觉一样.一般解决幻读的方法是增加范围锁RangeS，锁定检索范围为只读，这样就避免了幻读。 在数据库定义的四种隔离级别中 最高隔离级别SERIALIZABLE_READ可以保证不出现幻读的问题。 Repeatable Read (RR) 　　 针对当前读，RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，不存在幻读现象。 不可重复读 不可重复读，是指在数据库访问中，一个事务范围内两个相同的查询却返回了不同数据。 这是由于查询时系统中其他事务修改的提交而引起的。比如事务T1读取某一数据，事务T2读取并修改了该数据，T1为了对读取值进行检验而再次读取该数据，便得到了不同的结果。 一种更易理解的说法是：在一个事务内，多次读同一个数据。在这个事务还没有结束时，另一个事务也访问该同一数据。那么

锁：对 “某种范围” 的数据上 “某种锁” 1.“某种范围”：行、表 2.“某种锁” 2.1 共享锁Shared Locks（S锁） 1、兼容性：加了S锁的记录，允许其他事务再加S锁，不允许其他事务再加X锁 2、加锁方式：select…lock in share mode 2.2 排他锁Exclusive Locks（X锁） 1、兼容性：加了X锁的记录，不允许其他事务再加S锁或者X锁 2、加锁方式：select…for update 2.3 表锁：意向锁 Intention Locks，意向锁相互兼容 1、表明“某个事务正在某些行持有了锁、或该事务准备去持有锁” 2、意向锁的存在是为了协调行锁和表锁的关系，支持多粒度（表锁与行锁）的锁并存，。 3、例子：事务A修改user表的记录r，会给记录r上一把行级的排他锁（X），同时会给user表上一把意向排他锁（IX），这时事务B要给user表上一个表级的排他锁就会被阻塞。意向锁通过这种方式实现了行锁和表锁共存且满足事务隔离性的要求。 4、1）意向共享锁（IS锁）：事务在请求S锁前，要先获得IS锁 2）意向排他锁（IX锁）：事务在请求X锁前，要先获得IX锁 q1：为什么意向锁是表级锁呢？ 当我们需要加一个排他锁时，需要根据意向锁去判断表中有没有数据行被锁定（行锁）； （1）如果意向锁是行锁，则需要遍历每一行数据去确认； （2

MySQL半同步复制 从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时

视图、触发器、事务、存储过程、函数 阅读目录 一 视图 二 触发器 三 事务 四 存储过程 五 函数 六 流程控制 一 视图 视图是一个虚拟表（非真实存在），其本质是【根据SQL语句获取动态的数据集，并为其命名】，用户使用时只需使用【名称】即可获取结果集，可以将该结果集当做表来使用。 使用视图我们可以把查询过程中的临时表摘出来，用视图去实现，这样以后再想操作该临时表的数据时就无需重写复杂的sql了，直接去视图中查找即可，但视图有明显地效率问题，并且视图是存放在数据库中的，如果我们程序中使用的sql过分依赖数据库中的视图，即强耦合，那就意味着扩展sql极为不便，因此并不推荐使用 #两张有关系的表 mysql> select * from course; +-----+--------+------------+ | cid | cname | teacher_id | +-----+--------+------------+ | 1 | 生物 | 1 | | 2 | 物理 | 2 | | 3 | 体育 | 3 | | 4 | 美术 | 2 | +-----+--------+------------+ 4 rows in set (0.00 sec) mysql> select * from teacher; +-----+-----------------+ | tid |

前些天在查看关于 innodb_flush_log_at_trx_commit的官网解释时产生了一些疑问，关于 innodb_flush_log_at_trx_commit参数的详细解释参见官网： https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit 其中有一段是这么写的： With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. 意思是：如果 innodb_flush_log_at_trx_commit的值设为2，那么log buffer里的内容会在每次提交时被写入redo log file，然后redo log file每秒被flush到disk。 由于innodb的redo log file据我所知是在硬盘上的ib_logfile，所以对于这里的log file被flush到disk很疑惑，难道log

http://blog.itpub.net/28218939/viewspace-1975809/ 作者：沃趣科技MySQL数据库工程师 麻鹏飞 MySQL Binary log在MySQL 5.1版本后推出主要用于主备复制的搭建，我们回顾下MySQL 在开启/关闭 Binary Log功能时是如何工作的 。 MySQL 没有开启 Binary log的情况下： InnoDB存储引擎通过redo和undo日志可以safe crash recovery数据库，当数据crash recovery时，通过redo日志将所有 已经在存储引擎内部提交的事务应用 redo log 恢复 ，所有已经prepared但是 没有 commit 的 transactions 将会应用 undo log 做 roll back 。然后客户端连接时就能看到已经提交的数据存在数据库内，未提交被回滚地数据需要重新执行。 MySQL 开启 Binary log 的情况下： 为了保证存储引擎和MySQL数据库上层的二进制日志保持一致（ 因为备库通过二进制日志重放主库提交的事务，假设主库存储引擎已经提交而二进制日志没有保持一致，则会使备库数据丢失造成主备数据不一致 ），引入二阶段提交（two phase commit or 2pc） 图1 二阶段提交 MySQL二阶段提交流程： Storage Engine

【参考文章】： MySQL中Redo与Binlog顺序一致性问题？ 【参考文章】： 极客时间 1. 数据更新时的日志处理流程 　　 1.1 redo log（prepare状态） 　　此时SQL已经成功执行了，已经产生了语句的redo和undo内存日志，已经进入了事务commit步骤。然后告诉引擎做Prepare完成第一阶段，Prepare阶段就是写Prepare Log（Prepare Log也是Redo Log），将事务状态设为TRX_PREPARED，写Prepare XID（事务ID号）到Redo Log。写XID到Redo Log的时候会一并把Redo Log刷新到磁盘，这个时候Redo Log的日志量大小取决于执行SQL语句时产生的Redo是否被刷盘，这个刷盘是随机的，后台Master线程每秒钟都会刷新一次。 1.2 binlog 　　如果事务涉及的所有存储引擎的Prepare（ 即Redo Log写入磁盘之后 ）都执行成功，则调用TC_LOG_BINLOG::log_xid方法将SQL语句写到Binlog（write()将binary log内存日志数据写入文件系统缓存，fsync()将binary log文件系统缓存日志数据永久写入磁盘），同时也会把XID写入到Binlog。此时，事务已经铁定要提交了。否则，调用ha_rollback_trans方法回滚事务

1.概念:一条或者多条sql语句的集合！ 事务：就是一堆操作的集合，他们同生共死。要么都执行成功，要么都执行失败 2.事务的特性 ACID A：原子性 完整的，不可分割的 　　原子性 (Atomicity)：在事务中的操作，要么都执行，要么都不执行！ C: 一致性 事务执行完毕后，数据的状态是一致的（） 　　一致性（Consistency）：事务必须保证数据库从一个一致性的状态变成另一个一致性的状态！ I: ISOLation 隔离性 两个事务执行互不影响 　　隔离性（Isolation）:每个事务之间互不干扰！哪怕是并发执行也不干扰！ D: 永久性 事务执行完后，对数据的影响是永久的。 　　持久性（Durability）:事务一旦被改变，那么对数据库中数据的影响是永久性的！ 3.事务操作的关键字 自动提交事务开关set autocommit=1 开始事务 start transaction /begin 提交事务 commit 回滚事务 rollback set autocommit=1 4.事务+++存储过程 转账的例子 DELIMITER $$ CREATE PROCEDURE usp_transfer() BEGIN ##错误总数默认是0 DECLARE t_error INTEGER DEFAULT 0; ## continue 继续 hanlder 执行 并且对 t

　　　　　　　　　　　　　　　 　 事务 1.概念 一条或者多条sql语句的集合！ 事务：就是一堆操作的集合，他们同生共死。要么都执行成功，要么都执行失败 2.事务的特性 ACID A：原子性 完整的，不可分割的 　　原子性 (Atomicity)：在事务中的操作，要么都执行，要么都不执行！ C: 一致性 事务执行完毕后，数据的状态是一致的（） 　　一致性（Consistency）：事务必须保证数据库从一个一致性的状态变成另一个一致性的状态！ I: ISOLation 隔离性 两个事务执行互不影响 　　隔离性（Isolation）:每个事务之间互不干扰！哪怕是并发执行也不干扰！ D: 永久性 事务执行完后，对数据的影响是永久的。 　　持久性（Durability）:事务一旦被改变，那么对数据库中数据的影响是永久性的！ 3.事务操作的关键字 自动提交事务开关set autocommit=0 开始事务 start transaction /begin 提交事务 commit 回滚事务 rollback set autocommit=1 4.事务+++存储过程 转账的例子 DELIMITER $$ CREATE PROCEDURE usp_transfer() BEGIN ##错误总数默认是0 DECLARE t_error INTEGER DEFAULT 0; ## continue