数据库事务

各位老铁们，本周老张的《MySQL王者晋级之路》一书终于出版了，现在可以预购啦！ 预购链接地址： 老张的数据库微店 前前后后经历了一年的准备时间，可谓十年磨一剑，把自己从业所有的精华和心血都灌输到其书中。其书中包含了MySQL方方面面的知识点，是之前我的一篇博客“从青铜到王者，快速提升你MySQL数据库段位的全面深入剖析”。用一句学生对我说得话，老师喜欢您的王者荣耀情怀，但更喜欢您的技术情操。讲真，不要错过！特别感谢在我从事技术道路上，帮助过我的前辈及兄弟们，这条路上的所有的辛酸，只有你们最懂我！也要感谢对我博客一直支持的兄弟们！ 今儿的这篇博文，可以让大家快速了解GTID特性，并能灵活地运用到生产环境中，希望对大家有帮助。 GTID原理介绍 GTID又叫全局事务ID（Global Transaction ID），是一个已提交事务的编号，并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。 GTID是由server_uuid和事务id组成的，即GTID = server_uuid:transaction_id。 server_uuid是在数据库启动过程中自动生成的，每台机器的server-uuid不一样。uuid存放在数据目录的auto.cnf文件下。而transaction_id就是事务提交时由系统顺序分配的一个不会重复的序列号。

前言： 什么是事务？ 事务是程序中一系列严密的操作，所有操作执行必须成功完成，否则在每个操作所做的更改将会被撤销，这也是事务的原子性（要么成功，要么失败）。 MySQL的事务是在存储引擎层实现。 MySQL的事务有ACID A：原子性(atomicity)：一个事务必须被视为一个不可分割的单元。 C：一致性(consistency)：数据库是从一种状态切换到另一种状态。 I：隔离性(isolation)：事务在提交之前，对于其他事务不可见。 D：持久性(durablity)：一旦事务提交，所修改的将永久保存到数据库。 1、事务的基本语法 <!--创建表--> mysql> create table bank -> ( -> name varchar(25), -> money float -> ); Query OK, 0 rows affected (0.00 sec) mysql> insert into bank values('lu','1000'),('qi','5000'); <!--插入数据--> Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> begin; <!--begin开启事务，start transaction也可开启事务--> Query OK

视图 1.什么是视图？ 视图就是通过查询得到的一张虚拟表，然后保存下来，下次直接使用即可 2.为什么要用视图？ 如果要频繁使用一张虚拟表，可以不用重复查询 3.如何使用视图？ create view 视图名 as select * from 表 inner join 表 on 条件； 强调 1.在硬盘中，视图只有表结构文件，没有表数据文件 2.视图一般只适用于查询，不推荐修改视图的数据，如果修改的话会将原数据进行修改。 修改视图：当组成视图的基本表发生变化后可以通过修改视图来保持于基本表的一致性CREATE OR replace VIEW 视图名 AS SELECT * FROM 基本表；删除视图drop view 视图名； 为什么开发过程中不会使用视图 视图是mysql的功能，如果项目中使用大量的视图，在你想要扩充功能的时候如果这个视图需要对视图修改的话，就需要先将mysql这边的视图修改后去应用程序中修改对应的sql语句，这样的话需要跨部门沟通，所以通常不会使用视图，而是通过修改sql语句进行扩展功能。 触发器 是一种保证数据完整性的方法。由事件来触发并非由程序调用和手动启动。 为什么使用触发器？ 触发器是针对于对于某张表数据增insert，改update，删delete的行为，这类操作行为一旦执行就会触发触发器的执行，即自动执行另一端sql代码 创建触发器语法 #针对插入

自建商城在设计之初，业务部门就提出了两个要求： 不崩 & 快速上线。 在立项之后，团队还没有完全配备好，一边从其他团队里调取人手，一边大力招聘，与此同时，我们的架构师也在搭建一套分布式商城开发框架，编写 Demo，让新加入的同学能快速上手。 暴露问题 问题一： 分布式事务 为什么会使用分布式事务？ 这个暂且可以归因于快速上线，因为生成订单会调用到商品服务扣减库存，使用了分布式事务解决了因为跨服务调用引起库存超卖的问题，带来的问题就是性能上的消耗。 问题二： 数据库压力 在大促活动期间，有个实时统计是直接从业务库上直接查询统计的，运营部门的小姐姐在不断地刷新，导致该接口上的压力山大，而且没有使用缓存，连 SQL 查询条件的时间都是动态的，导致 DB 层的缓存也使用不上，每次请求都打到 DB 上。 开发和测试环境是使用自建的 MySQL，生产环境使用的是 PolarDB，从阿里云官网上看到： 集群架构，计算与存储分离 读写分离 我们主观地认为，只要我们使用了集群连接地址就会自动进行读写分离，但是实际上并没有，后来发现在方法上显式的指定只读事务就有请求走到只读节点上了。 @Transactional(readOnly = true) # 优化思路： 1）从 SQL 洞察和慢 SQL 里找调用响应时间最长和频度最高的 SQL； 2）结合代码，能用缓存代替的直接处理掉，不用能缓存的优化查询

===================================== 2019-05-15 19:31:18 0x1764 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 20 seconds BACKGROUND THREAD srv_master_thread loops: 137 srv_active, 0 srv_shutdown, 8488 srv_idle srv_master_thread log flush and writes: 8625 ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 247 OS WAIT ARRAY INFO: signal count 221 RW-shared spins 0, rounds 174, OS waits 95 RW-excl spins 0, rounds 296, OS waits 9 RW-sx spins 1, rounds 7, OS waits 0 Spin rounds per wait: 174.00 RW-shared, 296.00 RW-excl

数据库事务：一件完整的事情， 要么全部成功，要么就全部失败 金典案例：转账 A给B转账：100 A:-100 B:+100 如何开启事务： Start transaction; 之前的转账操作（如果在转账过程中出现异常：rollback） Commit; 事务的特性（ACID）: 原子性：要么全部成功 要么全部失败 不可以分割 一致性：事务前后，所有的状态都要保持一致 隔离性：一个事务最好不要受到其他事务的影响 持久性：将提交或者回滚的事务 存储到数据库中 不考虑隔离性： 脏读：读取到另一个事务中未提交的数据 不可重复读：在同一个事务中，两次查询结果不一样（update） 虚读（幻读）：在同一个事务中，两次查询结果不一样（insert） 隔离级别： 1）read uncommitted : 读取尚未提交的数据 ：哪个问题都不能解决 2）read committed：读取已经提交的数据 ：可以解决脏读 ---- oracle默认的 3）repeatable read：重读读取：可以解决脏读 和 不可重复读 ---mysql默认的 4）serializable：串行化：可以解决 脏读 不可重复读 和 虚读---相当于锁表 查看数据库的隔离级别： Select @@tx_isolation; Mysql 默认的隔离级别：repeatable-read; Oracle ： read

大纲 1.什么是事务？ 2.事务的四大特性ACID 3.数据库的四种隔离级别 4.事务并发执行会出现的问题 1.什么是事务（Transaction）？ 　　一组操作，要么全部执行成功，要么全部不执行。事务由一组操作组成，其中任一操作发生错误，则回滚之前成功的操作。 2.数据库事务的四大特性ACID 　　 原子性（Atomicity） ：事务是一个不可分割的执行单元，事务包含的全部操作要么全部执行成功，要么全部失败回滚。也即成功则完全应用到数据库，失败则对数据库不产生任何变更。 　　 一致性（Consistency） ：事务开始前和结束后， 数据库的完整性约束（存储在数据库中的所有值都是正确的） 没被破坏。 　　 隔离性（Isolation） ：每个事务相互独立，互不干扰，一个事务无法看到另一个事务中的数据。 　　 持久性（Durability） ：事务执行完成，其结果是持久化保存的。即使数据库发生崩溃，数据库恢复后事务提交的结果仍然存在（当然如果数据无法恢复的另说）。 3.数据库的四种隔离级别 　　 Serializable (串行化)： 可避免脏读、不可重复读、幻读的发生。 　　 Repeatable read (可重复读)： 可避免脏读、不可重复读的发生。 　　 Read committed (读已提交)： 可避免脏读的发生。 　　 Read uncommitted (读未提交

3种事务模型 本地事务模型 本地事务模型的名称来自于它实际上不是管理事务的框架，而是本地资源管理器。资源管理器是与之通信的数据源的实际提供者。例如，对于数据库，资源管理器是通过数据库驱动程序和DBMS实现的。对于JMS，资源管理器是通过特定的JMS提供程序实现的队列（或主题）连接工厂。使用本地事务模型，开发人员管理连接，而不是事务。实际管理本地事务的是DBMS或JMS提供程序。关于本地事务， 事实是事务管理由底层数据库(DBMS)处理，如果是jms，则由底层消息传递提供程序处理。从开发人员的角度来看，我们不管理本地事务模型中的事务，而是管理连接 。下面的代码示例演示了使用直接JDBC代码的本地事务模型的使用： public void updateTradeOrder(TradeOrderData order) throws Exception { DataSource ds = (DataSource) (new InitialContext()).lookup( "jdbc/MasterDS"); Connection conn = ds.getConnection(); conn.setAutoCommit(false); Statement stmt = conn.createStatement(); String sql = "update trade_order ...

事务的四大特性 原子性（atomic）： 事务是不可分割的工作单元，对于数据的修改，要么都执行，要么都不执行 。 只有事务中的所有操作都成功了，才算完成整个事务，事务中的任何一个sql语句执行失败，那么成功的sql语句也必须撤销，数据库状态应该回到执行事务之前的状态。 一致性（consistent）： 事务完成时，必须使所有的数据都保持一致状态。 数据库事务不能破坏关系数据的完整性一级业务逻辑上的一致型。了如银行转账事务，不管成功是否，应该保事务结束后两个转账账户的存款总额是一致的。 隔离性（insulation） 事务的并发所修改必须和任何其他并发事务所作的修改 隔离。当不同事务同时操作相同的数据时候，每个事务都有各自的完整数据空间。 持久性（duration）：事务完成之后，他对于系统的影响是永久性的。 它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。 事务的并发 为了获得更好的运行性能，各种数据库都允许多个事务同时运行，就是事务的并发 隔离机制 　　 当并发的事务风闻或者修改数据库中的相同的数据（同一行同一列）必须采取隔离机制 　　解决并发的途径是： 有效的隔离机制 　　实现事务的隔离：实现必须用锁（悲观锁，乐观锁，MQ) 并发出现的问题 脏读：数据已修改事务没提交，另一事务读取到未提交的数据！

本文实验的测试环境：Windows 10+cmd+MySQL5.6.36+InnoDB 一、事务的基本要素（ACID） 　　 1、原子性（Atomicity）： 事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 　　 2、一致性（Consistency）： 事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 　　 3、隔离性（Isolation）： 同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 　　 4、持久性（Durability）： 事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 二、事务的并发问题 　　1、脏读： 事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据 　　2、不可重复读： 事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。 　　3、幻读： 系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级