mysql事务

前言 在前几篇中，我们对MySQL的内部结构进行了介绍，对InnoDB的内部结构和核心机制进行了了解，本篇，我们继续深入InnoDB引擎，对InnoDB的锁机制进行简要的介绍。 InnoDB锁类型 在前面的文章中，我们介绍过，为了高性能的支持， InnoDB 实现了标准的行级锁。行级锁的意思代表着仅对指定的记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。因此，InnoDB可以支持较高的并发性。 InnoDB可以支持的锁的类型如下： 共享锁 排他锁 意向锁 记录锁 区间锁/间隙锁 临键锁 插入意向锁 自增锁 那么下面，我们对这些类型的锁进行依次介绍。 共享锁与排他锁（Shared and Exclusive Locks） InnoDB 实现了标准的行级锁，分为两种类型： 共享（S）锁 和 排他（X）锁 。 共享(S) 锁允许持有该锁的事务读取行。 排他(X) 锁允许持有该锁的事务更新或删除行。 如果事务T1在行A上持有共享（S）锁，则其他事务T2对行A的锁的请求按如下方式处理： 可以立即授予T2对S锁的请求。 结果，T1和T2都在r上持有S锁。 T2的X锁定请求不能立即授予。 如果事务T1在行B上持有排他（X）锁，则不能立即授予其他事务T2对行B上任何类型的锁请求。 相反，T2必须等待T1释放其对行B的锁定。 总结一下，如果对一行记录加共享锁

目录 前言 分布式事务方案 强一致性 2PC 两阶段提交（XA事务，阻塞） 3PC三阶段提交(非阻塞，引入超时和准备阶段) TCC模式-本质也是2PC Saga模式 最终一致性（BASE理论） 本地消息表 MQ消息队列 Paxos Raft ZAB 协议 ( Zookeeper Atomic Broadcast) 原子广播协议 总结 前言 如果只有一个数据库，所有的逻辑都在一个db完成，那么本地事务很简单就可以处理。但是，在微服务架构中，功能服务化，服务拆分化，一个业务逻辑很可能需要多个service完成，每个service操作不同的数据库，分布式事务需要一套方案来实现，本文就来集中讲述一下分布式事务的常见方案。 比如我们支付宝余额转入到余额宝，支付宝余额和余额宝是不同的服务，再比如跨行转账，从你的工商银行账户A转1000到建设银行账户B，比如订单系统和库存系统，其实有些情况下不一定要利用分布式事务，能避免尽力避免，主要看业务场景的需要，究竟是强一致性，弱一致性，还是最终一致性。 电商系统常见的例子：订单支付的时候使用红包或者优惠券，必需同时成功或者失败 常见对分布式事务场景： 跨库事务 分库分表，分库分表之后，一般可以利用mycat等数据库中间件简化开发，但是数据库中间件也面临分布式事务的问题 SOA架构（跨应用） 分布式事务方案 强一致性 2PC 两阶段提交（XA事务，阻塞）

近期公司项目基于微服务架构需要涉及到实现一套分布式事务。经过几天在网上查阅资料发现大部分文章只是讲解了具体的其中一个模型。因此在这里做一个总结+自己的一些感悟和看法。 1.CAP理论 CAP理论本身并不是一套和事务相关的理论，而是用来解释分布式系统的理论。但是用来分析分布式事物的边界非常适合。关于CAP理论，可以查看阮一峰大神的这篇文章： CAP定理的含义 CAP理论一个核心论证就是P(分区容错性)作为一个分布式系统是肯定包含的。因此实际实现只是在CP和AP之间做抉择。 CP：为了保证一致性和分区容错性，那么肯定会丧失一部分可用性。 AP：为了保证可用性和分区容错性，那么肯定会丧失一部分一致性。 2.ACID原则 ACID原则是用来描述一个事务应该包含的特性。原子性、一致性、隔离性、持久性。这个原则实际上和CAP理论是相悖的。 3.刚性事务、CP模式、XA协议 我们来假设一个简单的支付场景， 生成订单--->扣用户积分--->核销优惠劵--->修改订单状态 。这里涉及三个系统，订单系统、用户积分系统、优惠劵系统。那么如果我们要保证事务的一致性，我们在其中的每一步都会将资源锁定，然后只有在最终事务全部完成后，我们才能释放锁。那么在整个事务周期内我们的功能必定是处于不可用状态。这也正符合 CP定义 。这么做的事务确实可以保证事务的ACID原则，但是因为锁定时间长、锁粒度大(锁定资源多)

Java Web系列文章汇总贴: Java Web知识总结汇总 分布式事务基本理论 基本概念 通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库（可以是不同的应用对应的数据库）。对数据库的操作发生在系统的各处但必须全部被提交或回滚 。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么。因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）映射到全局事务中。 2PC、3PC基本概念 2PC,3PC主要是基于分布式事务的分布式一致性算法（因为分布式事务也可能会导致数据的不一致问题，这跟副本的不一致性从大类上看是都归于数据的不一致）。 在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是

目录 1. Mysql 1.1. 介绍 1.1.1 基础 1.1.3 数据库操作 1.2. 查询 1.2.1 条件 1.2.2 聚合 1.2.3 分组 1.2.4 排序 1.2.4 分页 1.3. 高级 1.3.1 关系 1.3.2 连接 1.3.3 自连接 1.3.4 子查询 1.3.5 内置函数 1.3.6 视图 1.3.7 事务 1.4. 与python交互 1.4.1 交互类型 1.4.2 增改删 1.4.3 查询 2. MongoDB 2.1. 基本操作 2.1.1 安装 2.1.2 数据库操作 2.1.3 集合操作 2.1.4 数据类型 2.1.5 数据操作 2.1.6 数据查询 2.2 高级操作 2.3 与python交互 3. redis 3.1 安装 3.2 基本配置 3.3 数据操作 3.3.1 string 3.3.2 键的命令 3.3.3hash 3.3.4 list 3.3.5 set 2.3.6 zset 3.4 与python交互 数据库系统解决的问题：持久化存储，优化读写，保证数据的有效性 当前使用的数据库，主要分为两类 文档型，如sqlite，就是一个文件，通过对文件的复制完成数据库的复制 服务型，如mysql、postgre，数据存储在一个物理文件中，但是需要使用终端以tcp/ip协议连接，进行数据库的读写操作 1. Mysql 1.1. 介绍

介绍： InnoDB给 MySQL 提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。 Innodb 的创始人：Heikki Tuuri Heikki Tuuri在Innodb的Ｂｕｇ社区里也是很活跃的，如果遇到Ｂｕｇ也可以直接提到社区，得到作者的解答。 为什么要学习Innodb的调优： 目前来说：InnoDB是为Mysql处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。 另一方面，在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。 参数调优内容： 1. 内存利用方面 2. 日值控制方面 3. 文件IO分配，空间占用方面 4. 其它相关参数 1.内存利用方面： 首先介绍一个Innodb最重要的参数： innodb_buffer_pool_size

1.索引、B树、B+树 MySQL的MyISAM、InnoDB引擎默认均使用B+树索引。 唯一索引：不允许其中任何两行具有相同值的索引 。 主键索引：可以认为是特殊的唯一索引，仅利用主键建立的索引 单一索引：任何一个单一数据项建立的索引 复合索引：多个数据项建立的索引 聚簇索引：利用主键建立的索引，其物理存放顺序与主键顺序一致。因为数据只有一个物理存放顺序，所以一个表只有一个聚簇索引。 非聚簇索引(二级索引，辅助索引)：除了聚簇索引之外，其余所有的索引都是非聚簇索引 覆盖索引：一个索引包含(覆盖)所要查询的字段的值，注意覆盖索引与具体的查询有关 索引为了快速检索数据。 B+ Tree索引(MySQL，SQL Server，Oracle) 修改key与子树的组织逻辑，将索引访问都落到叶子节点 按顺序将叶子节点串起来（方便范围查询） B+ Tree索引优点   ①.全值匹配：指的是和索引中所有列进行匹配。假设以(姓，名，出生日期)三个数据项建立复合索引，那么可以查找姓名为张三，出生日期在2000-12-12的人   ②.匹配最左前缀：假设以(姓，名，出生日期)三个数据项建立复合索引，可以查找所有姓张的人   ③.匹配列前缀：假设有姓为司徒，司马的人，我们也可以查找第一列的前缀部分，如查找所有以司开头的姓的人   ④.匹配范围值：可以查找所有在李和张之间的姓的人

数据库分区、分表、分库、分片 分区 数据库分区是一种物理数据库的设计技术，它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。 分区并不是生成新的数据库表，而是将表的数据均匀分摊到不同的硬盘，系统或不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据分摊到不同的地方，提高数据检索的效率，降低数据库频繁IO压力值，分区的优点如下： 相对于单个文件系统或硬盘，分区可以存储更多的数据。 数据管理比较方便，如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可。 精准定位分区查询数据，不需要全表扫描查询，大大提高检索效率。 可跨多个分区磁盘查询，来提高查询的吞吐量。 在涉及聚合函数时，很容易进行数据的合并。 水平分区 这种形式分区是对表的行进行分区，通过这种的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分体或集体分割。所有在表中定义的列在每个数据集中都能找到，所以表的特性得以保持。 举例：一个包含十年发票记录的表可以被分区为10个不同的分区，每个分区包含的是其中一年的记录。 垂直分区 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。 举例：一个包含了大text和blob列的表，这些text和blod列又不经常被访问

事务的特性: 原子性: 强调事务中的多个操作时一个整体(Atomicity) 一致性: 强调数据库中不会保存不一致状态性(Consistency) 隔离性: 强调数据库中事务之间相互不可见(Isolation) 持久性: 强调数据库能永久保存数据，一旦提交就不可撤销(Durability) 模式 MySQL数据库默认采用自动提交(autocommit)模式, 也就是说修改数据(insert、update、delete)的操作会自动的触发事务,完成事务的提交或者回滚 开启事务使用 begin 或者 start transacti开启事务后执行修改命令，变更数据会保存到MySQL服务端的缓存文件中，而不维护到物理表中 MySQL数据库默认采用自动提交(autocommit)模式，如果没有显示的开启一个事务,那么每条sql语句都会被当作一个事务执行提交的操作 当设置autocommit=0就是取消了自动提交事务模式，直到显示的执行commit和rollback表示该事务结束。 set autocommit = 0 表示取消自动提交事务模式，需要手动执行commit完成事务的提交on; 回滚事务使用 rollback; pymysql 里面的 conn.commit() 操作就是提交事务：将本地缓存文件中的数据提交到物理表中，完成数据的更新。 pymysql 里面的 conn

oracle查看被锁的表和解锁 --以下几个为相关表 SELECT * FROM v$lock; SELECT * FROM v$sqlarea; SELECT * FROM v$session; SELECT * FROM v$process ; SELECT * FROM v$locked_object; SELECT * FROM all_objects; SELECT * FROM v$session_wait; --查看被锁的表 select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; --查看那个用户那个进程照成死锁 select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time; --查看连接的进程 SELECT sid, serial#, username, osuser FROM v$session; --3.查出锁定表的sid, serial#,os_user_name,