mysql事务

《MySQL实战45讲》 Rows_examined：https://blog.csdn.net/weixin_34332905/article/details/90683568 恢复数据库：https://blog.51cto.com/laobaiv1/1960846 性能优化：https://www.cnblogs.com/angelica-duhurica/p/11303281.html 1 MySQL有哪些“饮鸩止渴”提高性能的方法 1.1 短连接风暴 解决： 方法1 先处理掉那些占着连接但是不工作的线程。 建议是处理掉查询任务之类的连接，插入的就不处理，避免数据库状态有损 方法2 减少连接过程的消耗。 让数据库跳过权限验证阶段 1.2 慢查询性能问题 在MySQL中，会引发性能问题的慢查询，有以下三种可能： 索引没有设计好； SQL语句没写好； MySQL选错了索引。 1.2.1 索引没有设计好 ⼀般通过紧急创建索引来解决 MySQL 5.6版本以后，创建索引都支持Online DDL了，对于那种高峰期数据库已经被这个语句打挂了的情况，最高效的做法就是直接执行alter table 语句。 比较理想的是能够在备库先执行； 假设现在的服务是⼀主⼀备：主库A、备库B，这个方案的大致流程是这样的： 在备库B上执行 set sql_log_bin=off ，也就是不写binlog

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

数据库隔离级别通俗解释： 读未提交：一个事务还没提交时，它做的变更就能被别的事务看到 读提交：一个事务提交以后，它做的变更才会被其他事务看到 可重复读：一个事务执行过程中看到的数据，总是跟这个事务在启动时候看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的 串行化：对于同一个记录，“写”会加“写锁”，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才可以继续执行。 MYSQL的MVCC: MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。 在Mysql的InnoDB引擎中就是指在已提交读(READ COMMITTD)和可重复读(REPEATABLE READ)这两种隔离级别下的事务对于SELECT操作会访问版本链中的记录的过程。 这就使得别的事务可以修改这条记录，反正每次修改都会在版本链中记录。SELECT可以去版本链中拿记录，这就实现了读-写，写-读的并发执行，提升了系统的性能。 我们来具体看看是如何实现的。 版本链 我们先来理解一下版本链的概念。在InnoDB引擎表中，它的聚簇索引记录中有两个必要的隐藏列： trx_id这个id用来存储的每次对某条聚簇索引记录进行修改的时候的事务id。 roll

做为开发人员对数据库事务应该都不陌生，但是如果知其然而不知其所以然的话，在开发中难免写出来的代码存在bug，本文主要介绍mysql中的事务，重点讲解事务的隔离级别。 1. ACID 1.1 原子性 原子性是指事务是一个不可分割的工作单位，事务中的操作要么全部执行，要么全部都不执行。 例如： begin // 开启事务 A：update user set account=account+1 where id =1; B：update user set account=account+1 where id =1; commit 这个事务，执行commit时，在么两条语句都执行成功，如果出错，执行rollback时，两条语句的操作都会回滚到原始状态； undo log保证原子性 在操作任何数据之前，首先将数据备份到一个地方（这个存储数据的地方就是undo log）。然后进行数据的修改，如果用户出现了错误或者用户执行了rollback语句，系统可用利用undo log中的备份的数据恢复到事务开始之前的状态。 注意：undo log是逻辑日志 可以理解为： 当delete一条记录时，undo log中记录一条对应的insert记录 当insert 一条记录时，undo log中会记录一条对应的delete记录 当update一条记录时，它记录一条对应相反的udpate记录 1.2 一致性

Java 事务机制 标签（空格分隔）： jdbc 事务 java 事务的属性 原子性：对数据要么不修改，要么修改全部执行 一致性：事务执行前后数据状态不发生改变 隔离性：一个事务的处理结果不能影响另一个事务的处理 持续性： 事务处理结束，其效果在数据库中持久化。 隔离及隔离级别 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 可重复读是指， 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。 当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 Oracle 数据库默认的隔离级别是“读提交”，因此，对于Oracle迁移到Mysql的应用，为保证数据库隔离级别的一致，要将Mysql的隔离级别设置为“读提交”。 事务中可能出现的问题 脏读 事务A读取了事务B未提交的数据，事务B发生错误进行回滚。 不可重复读 事务A的操作导致事务B在操作过程中两次读的数据不一致。 幻读 事务A查询到的内容之后，事务B 新增 了能匹配A查询的内容，使得事务A的两次查询不一致。 不可重复读针对的是update跟delete，幻读针对的是insert

Change Buffer 简介 当需要更新一个数据页的时候，如果数据页在内存中，则直接更新。如果这个数据页不在内存中，在不影响数据一致性的情况下，InnoDB会将这些更新操作缓存在change buffer 中，这样就不需要从内存中读取数据了。 那么，什么时候执行这些缓存的更新操作呢？ 在执行下次查询操作时，如果需要访问到这个数据页，会将其加载进内存，此时就可以进行更新操作，同时也设有定时更新的任务。 什么情况下会用到change buffer 对于唯一索引来说，所有的更新都需要判断是否违反唯一性约束，因此唯一索引是不能使用change buffer 的，针对普通索引的更新操作，并且涉及到的数据页不在内存中，此时就会用到change buffer。 使用场景 对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。 反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记 录在change buffer，但之后由于马上要访问这个数据页，会立即触发merge过程。这样随机访问 IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来 说，change buffer反而起到了副作用。 MVCC 多版本控制

锁 数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。 根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。 全局锁 全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。 全局锁的典型使用场景是，做全库逻辑备份 。也就是把整库每个表都select出来存成文本。 让整库都只读，听上去就很危险： 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆； 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。 官方自带的逻辑备份工具是mysqldump。当mysqldump使用参数–single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。 对于全部是InnoDB引擎的库，我建议你选择使用–single-transaction参数，对应用会更友好。

MySQL锁详解 一、概述 数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。MySQL各存储引擎使用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。 1.表级锁定（table-level） 表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。 当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。 使用表级锁定的主要是MyISAM，MEMORY，CSV等一些非事务性存储引擎。 2.行级锁定（row-level） 行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小

这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向操作, 都必须存在一个完全符合回滚规则的可逆操作, 这个操作通常叫做rollback或者cancel. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 为什么CA不行呢? 因为没有P的话, 数据一致性会出现问题, 这是任何一个一致性系统不允许出现的情况. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指强一致性事务, 例如单机环境下遵循ACID的数据库事务, 或者分布式环境中的2PC等. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 异步确保型, 最大努力通知型. 最佳实践 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性,

事前准备 为了故事的顺利发展，我们需要创建一个表： CREATE TABLE t ( id INT PRIMARY KEY, c VARCHAR(100) ) Engine=InnoDB CHARSET=utf8; 复制代码 然后向这个表里插入一条数据： INSERT INTO t VALUES(1, '刘备' ); 复制代码 现在表里的数据就是这样的： mysql> SELECT * FROM t; +----+--------+ | id | c | +----+--------+ | 1 | 刘备 | +----+--------+ 1 row in set (0.01 sec) 复制代码 隔离级别 MySQL 是一个服务器／客户端架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称之为一个会话（ Session ）。我们可以同时在不同的会话里输入各种语句，这些语句可以作为事务的一部分进行处理。不同的会话可以同时发送请求，也就是说服务器可能同时在处理多个事务，这样子就会导致不同的事务可能同时访问到相同的记录。我们前边说过事务有一个特性称之为 隔离性 ，理论上在某个事务对某个数据进行访问时，其他事务应该进行排队，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大，所以设计数据库的大叔提出了各种 隔离级别