mysql事务

什么是事务？ 事务由单独单元的一个或多个SQL语句组成，在这个单元中，每个MySQL语句是相互依赖的。而整个单独单元作为一个不可分割的整体，如果单元中某条SQL语句一旦执行失败或产生错误，整个单元将会回滚。所有受到影响的数据将返回到事物开始以前的状态；如果单元中的所有SQL语句均执行成功，则事物被顺利执行。 1. 为什么要讲InnoDB的事务呢？ 严格上来说，事务必须同时满足4个特性，即通常所说事务的ACID特性。虽然理论上定义了严格的事务要求，但是数据库厂商出于各种目的并没有严格满足事务的ACID标准。例如，对于MYSQL的NDB Cluster引擎，虽然支持事务，但是不满足D的要求，即持久性的要求。对于Oracle数据库来说，其默认的事务隔离级别为READ COMMITTED，不满足I的要求，即隔离性的要求。对于InnoDB存储引擎而言，默认的事务隔离级别是READ REPRATABLE，完全遵循和满足事务的ACID特性 2. 什么是事务的ACID 1. A(atomicity) 原子性。一个事务的执行被视为一个不可分割的最小单元。事务里面的操作，要么全部成功执行，要么全部失败回滚，不可以只执行其中的一部分。 2. C(consistency) 一致性。一个事务的执行不应该破坏数据库的完整性约束。如果上述例子中第2个操作执行后系统崩溃，保证A和B的金钱总计是不会变的。 3. I

1、打开mysql 本人由于重装了系统之后，不能快速正确找到mysql客户端，所以需要使用cmd窗口来运行命令行程序。 如果在打开cmd窗口时就使用mysql命令，会出现如下错误： 这是由于没有目前还未进入mysql数据库，所以不能执行mysq命令，故需要进入mysql的bin目录来启动mysql，如下图： 然后就可以顺利执行mysql的命令行了。 2、创建数据库 创建一个数据库，名字为world，如下图： 3、创建表 在创建数据库world成功后，再在其中创建一张表，名为test1，如下图： 4、插入数据 在test1表中插入4条学生信息的数据，包括名字、学校，如下图： 5、事务操作–删除 5.1、开启事务 5.2、执行事务 下面执行的事务是删除一条学生信息数据： 5.3、回滚事务 6、事务操作–更新 具体步骤同上。 7、事务提交 如果在执行事务完毕后，用commit提交，那么再回滚rollback就不能回到之前的状态了。如下例： 事务提交 事务回滚 一开始数据库有4条数据，执行删除事务删除了一条数据，所以为3条数据，提交事务后表中的状态为3条数据，再执行回滚事务操作，此时会发现事务回滚之后表的数据和事务提交之后表的数据一样，为3条，所以说明回滚不到提交之前的状态了。 - 来源： CSDN 作者： Alice_yufeng 链接： https://blog.csdn.net

GTID复制原理： 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID. 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次. GTID是由server_uuid和事物id组成，格式为：GTID=server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成，每台机器的server-uuid不一样。uuid存放在数据目录的auto.conf文件中，而transaction_id就是事务提交时系统顺序分配的一个不会重复的序列号。 GTID的好处： （1）GTID使用master_auto_position=1代替了binlog和position号的主从复制搭建方式，相比binlog和position方式更容易搭建主从复制。 （2）GTID方便实现主从之间的failover，不用一步一步的去查找position和binlog文件。

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构，供大家参考。 一、GTID的概念 1、全局事务标识：global transaction identifiers。 2、GTID是一个事务一一对应，并且全局唯一ID。 3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。 4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。 5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。 6、在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。 二、GTID的组成 GTID = source_id:transaction_id source_id，用于鉴别原服务器，即mysql服务器唯一的的server_uuid

Mysql5.6基于GTID全局事务的复制 什么是 GTID ？   GTID(Global Transaction Identifiers)是全局事务标识 当使用GTIDS时，在主上提交的每一个事务都会被识别和跟踪，并且运用到所有从MySQL，而且配置主从或者主从切换时不再需要指定 master_log_files和master_log_pos；由于GTID-base复制是完全基于事务的，所以能很简单的决定主从复制的一致性； 官方建议Binlog采用Row格式 MySQL 5.1.12 开始，可以用以下三种模式来实现： 基于SQL语句的复制(statement-based replication, SBR)， 基于行的复制(row-based replication, RBR)， 混合模式复制(mixed-based replication, MBR)。 相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默认的。 基于混合模式的复制：它是根据事件的类型实时的改变binlog的格式。当设置为混合模式时，默认为基于语句的格式，但在特定的情况下它会自动的转变为基于行的模式。 SBR 的优点： 历史悠久，技术成熟 binlog文件较小 binlog中包含了所有数据 库更改信息，可以据此来审核数据库的安全等情况

简介 参考https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-gap-locks。 InnoDB引擎实现了标准的行级别锁（S和X）。InnoDB引擎加锁原则遵循二段锁协议，即事务分为两个阶段，事务开始后进入加锁阶段，事务commit或者rollback就进入解锁阶段。InnoDB引擎下锁的影响因素很多，隔离级别不同，是否使用索引等都会产生不同的锁结果。 查看锁和事务 当出现ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，要解决是一件麻烦的事情。特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁，超时后结束，DBA光从数据库无法着手找出源头是哪个SQL锁住了。有时候看看 show engine innodb status， 并结合 show full processlist 能暂时解决问题，但一直不能精确定位。在5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）。 INNODB_LOCKS 提供有关InnoDB事务已请求但尚未获得的以及事务正在阻塞另一个事务的锁的信息。 lock_id InnoDB内部的唯一锁ID lock_trx_id

前言 事务是数据库中很重要的一种机制，作为一个后台开发人员，事务是我们必须要了解的机制。写下这篇文章，主要是为了能够加深我对事务的理解，也是为了以后可以方便查看。要了解事务，我们需要关注以下三个大佬： 事务的基本要素 、 事务的并发问题 、 事务的隔离级别 。下面就让我来依次介绍这三个大佬。 事务的基本要素（ACID） 原子性（Atomicity） ：一个事务里面的一系列操作要么全做，要么全不做，事务是不可分割的一个整体。 一致性（Consistency） ：事务开始前和结束后，数据库的完整性约束没有被破坏。一个事务的中间状态对外部不可见。比如，A向B转账，不可能出现A扣了钱，B却没有收到的情况。 隔离性（Isolation） ：同一时间只允许一个事物访问同一个数据，不同的事务之间彼此没有任何干扰。 持久性（Durability） ：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 注：原子性是事务隔离的基础，隔离性和持久性是手段，最终目的是为了保持数据的一致性。 事务的并发问题 脏读 ：事务A读取了事务B更新的数据，然后事务B回滚了，那么事务A读取的数据是脏数据。 不可重复读 ：事务A读取数据d1，事务B对数据d1进行更新操作并且提交了事务B，事务A再次读取数据d1，那么事务A第一次和第二次读取的数据不一致。 幻读 ：事务A查询id=1的数据，发现没有

前景 Mysql作为开源数据库的中坚力量之一，虽然目前已被甲骨文收购，面临闭源风险，但是mysql扔是我们运维工作中最常面对的工作，那如何做好mysql运维工作，甚至做好mysql的基础运维，都是维稳业务持久层的关键，故本文收集相关资料整理MySQL运维工作常用的命令，以作记录，供日常运维时参考查证。 Mysql运维 MySQL运维工作常用命令和操作主要包括：对MySQL数据库状态的查看、性能的优化（连接数，存储，集群等），MySQL表及索引的检查、分析、修复、优化，MySQL数据库的导出导入、冷热备份等。 1、工具篇 常用工具： 1）myisampack：压缩MySQL的MyISAM表以产生更小的只读表的一个工具。myisampack可以压缩MyISAM表来解决空间占用过大的问题。myisampack分别压缩表中的每一列。通常，myisampack可以将数据文件压缩到40%-70%。当以后使用表时，解压缩列需要的信息被读入内存。当访问具体的记录时性能会更好，因为你只需要解压缩一个记录。 2）mysqlaccess：检查访问主机名、用户名和数据库组合的权限的脚本。它可作为MySQL的一个诊断工具，检查访问权限的主机名、用户名和数据库组合。其检查功能只访问user、db和host这3个表，而不检查在tables_priv、columns_priv或procs_priv表等信息； 3

这段时间一直在学习 mysql 数据库。项目组一直用的是 oracle ，所以对 mysql 的了解也不深。本文主要是对 mysql 锁的总结。 Mysql 的锁主要分为 3 大类： 表级锁：存储引擎为 Myisam 。锁住整个表，特点是开销小，加锁快，锁定力度大，发生锁冲突的概率最高，并发度最低。 页级锁：存储引擎为 BDB 。锁住某一页的数据（ 16kb 左右），特点：开销和枷锁时间介于表级和行级之间；会出现死锁，锁定力度介于表锁和行锁之间，并发度一般。 行级锁：存储引擎为 innodb 。锁住某一行的数据，特点：锁的实现更加复杂，开销大，加锁速度慢。 根据以上特点，仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如 Web 应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（ OLTP ）系统。 接下来进行行级锁的详解，行级锁主要分为以下 7 类：共享 / 排他锁、意向锁、记录锁、间隙锁、临建锁、插入意向锁、自增锁。 共享 / 排他锁： 共享锁：又称读锁，可以允许读，但不能写。共享锁可以与共享锁一起使用。 语句： select ... lock in share mode 排他锁：又称写锁，不能允许读，也不能允许写，排他锁不能与其他所一起使用。 语句： select ... for

MGR整体架构及特点 　　single-master 　　　　只有一个节点写入，都可以读取 　　multi-master 　　　　每个节点都可以写入和读取 　　涉及到的概念： 　　　　group communication system (GCS) 　　　　writeset 　　　　membership 　　　　cerification info 　　　　flow control stats 　　　　paxos 　　MGR一致性读增强 　　group_replication_consistency (8.0.14引入） 　　　　EVENTUAL: 默认 　　　　BEFORE： 等待队列中的事务全部执行完 　　　　BEFORE_ON_PRIMARY_FAILOVER: 等待新primary执行完队列中事务 　　　　AFTER： 等待数据变更在其他所有节点全部被应用 　　　　BEFORE_AND_AFTER: 　　MGR限制 　　　　仅支持InnoDB，必须有主健 　　　　Binlog 格式: Row，关闭binlog checksum　　 　　　　必须开启GTID 　　　　事务隔离级别： READ COMMITTED （没有 gap lock）　　 　　　　大事务限制： group_replication_transaction_size_limit 　　　　Multi