mysql事务

视图 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）结合代码，能用缓存代替的直接处理掉，不用能缓存的优化查询

1.4多版本并发控制 Mysql的大多数事务型存储引擎的实现都不是基于简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。它的实现是通过保存数据再某个时间点的快照来实现的。当一个事务开始进行时，他无论花了多少时间执行多少次相同的查询，他看到的数据都是一致的。而不同的事务在不同时间点开始事务时，每个事务对同一张表、同一个时刻看到的数据可能都是不相同的。 以最经典的InnoDB引擎（隔离级别为REPEATABLE READ）为例，它的MVCC实现方法是通过在每行记录后面保存两个隐藏列来实现的。一个列保存行的创建时间，一个列用来保存列的过期时间（删除时间），他存储的不是实际的时间值，而是系统版本号，每当开始一个新的事务，系统版本号就会自动递增，该事务开始的时刻的版本号即为该事务的版本号，用来和该事务要查询的每行记录的版本号进行比较。 SELECT： InnoDB会根据以下两个条件检查每行记录： a.InnoDB只会查找版本小于或等于当前事务版本的数据行，这样可以保证事务读取的行要么在事务开始前已经存在了，要么是事务他自身插入或修改过的行。 b.行的删除版本要么未定义，要么要大于当前事务的版本号。这可以确保事务读取到的行，一定是在该事务开始时未被删除的数据行。 INSERT/DELETE： InnoDB为新插入（新删除的

===================================== 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 (读未提交

事务的四大特性 原子性（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等级

1,procedure 是一个可以用编程的方式来操作SQL的集合; 存储过程的优点？ 执行效率很高，因为存储过程是预编译的，即创建时编译，而SQL语句是执行一次，编译一次。调用存储过程可以大大减少同数据库的交互次数。 降低网络通信量，因为存储过程执行的时候，只需要call存储过程名，不需要传递大量的SQL语句。 有利于复用。 存储过程的缺点？ 移植性非常差，如果在oracle上写的存储过程，移植到mysql需要修改。 代码可读性差，实现一个简单的逻辑，代码会非常长。 存储过程的用途？ 造测试数据：可以使用存储过程，往表里造几百万条数据。 数据同步：两个表之间按照一定的业务逻辑进行数据同步。 数据挖掘。 存储过程注意事项？ 数据量大的时候（10万+），一定要做压力测试，有些存储过程在大数据量的情况下才会出现问题。 如果插入或者更新的次数比较多，为了提高效率，可以执行一万次，再commit一次。 如果先插入记录，没有commit，再对这条记录进行更新，会引起死锁。如果先后对同一笔记录进行更新，又没有commit，也会引起死锁。因为后一条语句会等待前一条语句提交。如果出现这种情况，则需要一条条commit。 不要忘记在存储过程里写commit。 2,Oracle什么时候需要commit? DML语言，比如update，delete，insert等 修改表中数据 的需要commit;

MySQL事务 MySQL事务主要用于处理操作量大，复杂度高的数据。 比如说，在人员管理系统中，你删除一个人员，你既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这些数据库操作语句就构成一个事务。 （1）在MySQL中只有使用了Innodb数据库引擎的数据库或表才支持事务。 （2）事务处理可以用来维护数据库的完整性，保证成批的sql语句要么全部执行，要么全部不执行。 （3）事务用来管理insert,update,delete语句。 一般来说，事务必须满足4个条件（ACID）：Atomicity(原子性)、Consisttency(稳定性)、Isolation(隔离性)、Durability(可靠性)。 （1）事务的原子性：一组事务，要么成功，要么撤回。 （2）事务的稳定性：有非法数据（外键约束之类的），事务撤回。 （3）事务的隔离性：事务独立运行。一个事务处理后的结果，影响了其他事务，要么其他事务会撤回。事务的100%的隔离，需要牺牲速度。 （4）事务的可靠性：软、硬件崩溃后，InnoDB数据库驱动会利用日志文件重构修改，可靠性和高速度不可兼得，innodb_flush_log_at_trx_commit选项，决定什么时候把事务保存到日志里。 在MySQL控制台使用事务来操作： （1）开始一个事务 start transaction （2）做保存点