mysql事务

截至目前，MySQL一共向用户提供了包括DBD、HEAP、ISAM、MERGE、MyIASM、InnoDB以及Gemeni这7种Mysql表类型。其中DBD、InnoDB属于事务安全类表，而其他属于事务非安全类表。 DBD Berkeley DB(DBD)表是支持事务处理的表，由Sleepycat软件公司开发。它提供MySQL用户期待已久的功能--事务控制。事务控制在任何数据库系统中都是一个极有价值的功能，因为它们确保一组命令能成功地执行或回滚。 HEAP HEAP表是MySQL中存取数据最快的表。这是因为他们使用存储在动态内存中的一个散列索引，不过如果MySQL或服务器崩溃，这些内存数据将会丢失。 ISAM ISAM表是早期MySQL版本的缺省表类型，直到MyIASM开发出来。建议不要再使用它。 MERGE MERGE是一个有趣的新类型，在3.23.25之后出现。一个MERGE表实际上是又一个MyISAM表的集合，合并而成的一个表，主要是为了效率的考虑，因为这样不仅仅可以提高速度、搜索效率、修复效率而且还节省了磁盘空间。 MyIASM MyIASM基于了IASM代码，应该可以说是IASM的衍生品，不过增加了不少有用的扩展。它是MySQL的默认数据表类型，基于了传统的ISAM类型，ISAM是Indexed Sequential Access Method（有索引的顺序访问方法

事务 1. 为什么要有事务 事务广泛的运用于订单系统、银行系统等多种场景 例如： A用户和B用户是银行的储户，现在A要给B转账500元，那么需要做以下几件事： 检查A的账户余额>500元； A 账户中扣除500元; B 账户中增加500元; 正常的流程走下来，A账户扣了500，B账户加了500，皆大欢喜。 那如果A账户扣了钱之后，系统出故障了呢？A白白损失了500，而B也没有收到本该属于他的500。 以上的案例中，隐藏着一个前提条件：A扣钱和B加钱，要么同时成功，要么同时失败。事务的需求就在于此 事务定义 所谓事务,它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位 例如，银行转帐工作：从一个帐号扣款并使另一个帐号增款，这两个操作要么都执行，要么都不执行。所以，应该把他们看成一个事务。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性 假如一个银行的数据库有两张表：支票表（checking）和储蓄表（savings）。现在要从用户Jane的支票账户转移200美元到她的储蓄账户，那么至少需要三个步骤： 1.检查支票账户的余额高于或者等于200美元。 2.从支票账户余额中减去200美元。 3.在储蓄帐户余额中增加200美元。 上述三个步骤的操作必须打包在一个事务中，任何一个步骤失败，则必须回滚所有的步骤。 事务四大特性(简称ACID)

sysbench是一个模块化的、跨平台、多线程基准测试工具，主要用于评估测试各种不同系统参数下的数据库负载情况。关于这个项目的详细介绍请看： https://github.com/akopytov/sysbench 。 它主要包括以下几种方式的测试： cpu性能 磁盘io性能 调度程序性能 内存分配及传输速度 POSIX线程性能 数据库性能(OLTP基准测试) sysbench的数据库OLTP测试支持MySQL、PostgreSQL、Oracle，目前主要用于Linux操作系统，开源社区已经将sysbench移植到了Windows，并支持SQL Server的基准测试。 废话不多说，开始。 1. sysbench安装 mysql版本: mysql-community-server-5.6.29 OS: CentOS 6.7 X86_64 sysbench 0.5相比0.4版本有一些变化，包括oltp测试结合了lua脚本，还多了一些隐藏选项，本文会涉及得到一部分。 目前许多仓库里已编译好的二进制sysbench还是0.4.x版本，不过现在主流也还是github上的0.5（我这里使用的是1.0），可以从 这里 下载0.5版本的rpm包直接安装，不过我选择自己编译，因为只有这个办法是通用的。 // 先安装编译依赖环境 $ sudo yum install gcc gcc-c++

1、主从复制概述 MySQL主从复制也可以称为MySQL主从同步，它是构建数据库高可用集群架构的基础。它通过将一台主机的数据复制到其他一台或多台主机上，并重新应用relay log中的SQL语句来实现复制功能。MySQL支持单向、双向、链式级联、异步复制，5.5版本之后加入的半同步复制，5.6版本之后的GTID复制，MySQL5.7的多源复制、并行复制、loss-less复制。 1.1 常见的几种主从架构 1）单向主从模式：Master ——> Slave 2）双向主从模式：Master <====> Master 3）级联主从模式：Master ——> Slave1 ——> Slave2 4）一主多从模式 5）多主一从模式 1.2 主从复制功能 1）实时灾备 2）读写分离 3）高可用 4）从库数据统计 5）从库数据备份 6）平滑升级 1.3 主从复制原理 主从同步过程中主服务器有一个工作线程I/O dump thread，从服务器有两个工作线程I/O thread和SQL thread。 主库把外界接收的SQL请求记录到自己的binlog日志中，从库的I/O thread去请求主库的binlog日志，并将binlog日志写到中继日志中，然后从库重做中继日志的SQL语句。主库通过I/O dump thread给从库I/O thread传送binlog日志。 原理图 !

在 数据库的锁机制 中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 悲观锁 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。 悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 悲观锁，正如其名，它指的是对数据被外界

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

一.mysql事件隔离级别 1未提交读（READUNCOMMITTED） 另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）( 隔离级别最低，并发性能高 ) 2…提交读（READCOMMITTED） 本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。会出现不可重复读、幻读问题（锁定正在读取的行) 3.可重复读（REPEATABLEREAD） 在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。会出幻读（锁定所读取的所有行） 推荐Python大牛在线分享技术 扣qun：855408893 领域：web开发，爬虫，数据分析，数据挖掘，人工智能 零基础到项目实战，7天学习上手做项目 4.串行化（SERIALIZABLE） 读操作会隐式获取共享锁，可以保证不同事务间的互斥（锁表) 二.脏读、不可重复读、幻读、复读 1.脏读 当前事务读到的数据是别的事务想要修改成为的但是没有修改成功的数据 2.不可重复读 当前事务先进行了一次数据读取，然后再次读取到的数据是别的事务修改成功的数据，导致两次读取到的数据不匹配，也就照应了不可重复读的语义 3.幻读

一、锁 1、锁的概述 InnoDB存储引擎中，事务的隔离性主要是由锁机制实现的。开发多用户的应用，很大的一个难点就在于并发访问：一方面既要最大程度地实现数据库的并发访问，另一方面又要确保每个用户能以一致的方式读取、修改数据，为此，我们需要锁机制。 锁机制是数据库系统区别于文件系统的另一个关键特性，锁机制用于管理对共享资源的并发访问，保证数据的完整性和一致性。这里的共享资源不仅仅是行数据，还包括缓冲池中的LRU列表，删除、添加、移动LRU列表中的元素时，有需要锁来保证一致性。 2、锁的类型 （1）共享/排他锁 MySQL提供了两种锁的粒度：行级锁、表级锁。一般而言，锁的粒度越小，并发度越高；锁用得越多，开销越大（锁的各种操作如获取锁、释放锁、检查锁状态等都会增加系统开销）。因此我们通常只锁定尽可能少的数据量，另外我们需要在锁开销和并发度之间找好平衡点。 InnoDB存储引擎提供两种行级锁： 共享锁（S Lock）：允许事务读一行数据； 排他锁（X Lock）：允许事务删除或更新一行数据。 如果事务T1已经获得行r的共享锁，那么事务T2可以立即获得行r的共享锁以读取数据（锁兼容）；如果事务T1已经获得行r的共享锁/排他锁，那么事务T2要想获得行r的排他锁/共享锁或排他锁必须等待事务T1释放锁（锁不兼容）。共享锁和排他锁均用在事务中，随着事务的结束而释放。 （2）意向锁

错误日志 log_error log_warnings 一般查询日志： general_log general_log_file log log_output 慢查询日志 long_query_time 超过这个时间的查询都是慢查询 log_slow_queries={YES|NO} slow_query_log slow_query_log_file 二进制日志：任何引起或可能引起数据库变化的操作； 复制、即时点恢复； mysqlbinlog 二进制日志的格式： 基于语句: statement 基于行: row 混合方式: mixed 二进制日志事件： 产生的时间 相对位置 二进制日志文件： 索引文件 二进制日志文件 mysql> SHOW MASTER STATUS; 查看当前正在使用的二进制日志文件 mysql> SHOW BINARY LOGS; 查看当前拥有的二进制文件 mysql> SHOW BINLOG EVENTS IN '二进制日志文件名' [FROM pos]；查看二进制文件记录的事件 mysql> PURGE BINARY LOGS TO '某二进制日志文件' 删除此文件之前的所有二进制文件，本文件不删除 mysql > flush logs 手动实现主服务器二进制日志滚动，从服务器会滚动中继日志 mysqlbinlog --start-datetime -

事务管理 回顾事务 事务：一组业务操作ABCD，要么全部成功，要么全部不成功。 特性：ACID 原子性：整体 一致性：完成 隔离性：并发 持久性：结果 隔离问题： 脏读：一个事务读到另一个事务没有提交的数据 不可重复读：一个事务读到另一个事务已提交的数据（update） 虚读(幻读)：一个事务读到另一个事务已提交的数据（insert） 隔离级别： read uncommitted：读未提交。存在3个问题 read committed：读已提交。解决脏读，存在2个问题 repeatable read：可重复读。解决：脏读、不可重复读，存在1个问题。 serializable ：串行化。都解决，单事务。 mysql 事务操作--简单 ABCD 一个事务 Connection conn = null; try{ //1 获得连接 conn = ...; //2 开启事务 conn.setAutoCommit(false); A B C D //3 提交事务 conn.commit(); } catche(){ //4 回滚事务 conn.rollback(); } mysql 事务操作--Savepoint 需求：AB（必须），CD（可选） Connection conn = null; Savepoint savepoint = null; //保存点，记录操作的当前位置