事务

面试的时候，发现数据库方面，忘得一塌糊涂，抽时间整理了一些数据库方面的题。 事务四大特性（ACID）原子性、一致性、隔离性、持久性？ 事务的并发？事务隔离级别，每个级别会引发什么问题，MySQL 默认是哪个级别？ MySQL 常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别？ MySQL 的 MyISAM 与 InnoDB 两种存储引擎在，事务、锁级别，各自的适用场景？ 查询语句不同元素（where、jion、limit、group by、having 等等）执行先后顺序？ 什么是临时表，临时表什么时候删除? MySQL B+Tree 索引和 Hash 索引的区别？ 聚集索引和非聚集索引区别？ 有哪些锁（乐观锁悲观锁），select 时怎么加排它锁？ 非关系型数据库和关系型数据库区别，优势比较？ 数据库三范式，根据某个场景设计数据表？ 数据库的读写分离、主从复制，主从复制分析的 7 个问题？ 使用 explain 优化 sql 和索引？ MySQL 慢查询怎么解决？ 什么是 内连接、外连接、交叉连接、笛卡尔积等？ mysql 都有什么锁，死锁判定原理和具体场景，死锁怎么解决？ varchar 和 char 的使用场景？ mysql 高并发环境解决方案？ 数据库崩溃时事务的恢复机制（REDO 日志和 UNDO 日志）？ 事务四大特性（ACID）原子性、一致性

6、事务 要么都成功，要么都失败 1、SQL 执行 A 给 B 转账 A 1000 —>200 B 200 2、SQL 执行 B 收到 A 的钱 A 800 —> B 400 一一一一一一 将一组SQL 放在一个批次中去执行~ 事务原则 ： ACID 原则 原子性，一致性，隔离性，持久性 （脏读，幻读….） 参考博客连接 ： https://blog.csdn.net/dengjili/article/details/82468576 原子性（Atomicity） 要么都成功，要么都失败 一致性（Consistency） 事务前后的数据完整性要保证一致 ，1000 持久性（Durability）— 事务提交 事务一旦提交则不可逆，被持久化到数据库中！ 隔离性（Isolation） 事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作 数据所干扰，多个并发事务之间要相互隔离。 隔离所导致的一些问题 脏读： 指一个事务读取了另外一个事务未提交的数据。 不可重复读： 在一个事务内读取表中的某一行数据，多次读取结果不同。（这个不一定是错误，只是某些场合不对） 虚读(幻读) 是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。 执行事务 -- ==================== 事务 =========================

1、MySQL默认存储引擎的变迁 在MySQL 5.1之前的版本中，默认的搜索引擎是MyISAM，从MySQL 5.5之后的版本中，默认的搜索引擎变更为InnoDB。 2、MyISAM与InnoDB存储引擎的主要特点 MyISAM存储引擎的特点是：表级锁、不支持事务和全文索引，适合一些CMS内容管理系统作为后台数据库使用，但是使用大并发、重负荷生产系统上，表锁结构的特性就显得力不从心； 以下是MySQL 5.7 MyISAM存储引擎的版本特性： InnoDB存储引擎的特点是：行级锁、事务安全（ACID兼容）、支持外键、不支持FULLTEXT类型的索引(5.6.4以后版本开始支持FULLTEXT类型的索引)。InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全存储引擎。InnoDB是为处理巨大量时拥有最大性能而设计的。它的CPU效率可能是任何其他基于磁盘的关系数据库引擎所不能匹敌的。 以下是MySQL 5.7 InnoDB存储引擎的版本特性： 注意： InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如 update table set num=1 where name like “a%” 。 两种类型最主要的差别就是InnoDB支持事务处理与外键和行级锁。而MyISAM不支持

DRP学习中，我们对可能引起并发操作的情况使用了锁，这次先理论上看看并发控制与锁的一些内容吧。 并发控制 在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是并发性。典型的冲突有： 1、丢失更新（Lost updates） 一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。 2、脏读（Dirty reads） 当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。 3、不可重复读（Non-repeatable reads） 当一个进程读取了一笔数据后，另一个进程更新了同一笔数据，然后第一个进程再次读取同一笔数据，却得到了 与第一次读取不同的结果。 在事务A更新记录之后（update Customers set Name = 'B' where Name = 'A'），事务B读取相同记录（select Name form Customers where Name = 'A'），但事务B拿到的是事务A更新之后的数据（Customers.Name的值为'B'），在事务B读取记录之后，事务A进行了事务回滚（Customers.Name的值为'A'），导致事务B的数据是不真实的。 4、幻读（Phantoms）

一、为什么要合并图表 说明：合并图表是为了更好的定位系统瓶颈，比如把虚拟用户运行图和平均响应事务时间合并，能直观体现虚拟用户数量 对服务器处理事务产生的影响； 二、Analysis合并图 1. Running Vusers(虚拟运行用户) 2. Average Transaction Response Time(平均事务响应时间) 说明：在合并之前，我们先拿两张图来演示 1). Running Vusers(虚拟运行用户) 2). Transaction Response Time(平均事务响应时间) 2.1 合并图操作说明 1. 操作说明： 1). 打开合并选项菜单 (Ctrl+M 或者 在要合并的图表上点击鼠标右键->merge Graphs) 2). 标1：选择要合并的图(并入) 如：Running Vusers 3). 标2：选择并入的方式： (1). Overlay(叠加) (2). Tile(平铺) (3). Correlate(关联) 2.2 合并方式-Overlay(叠加) 说明：两个图使用相同的X轴，并入的图Y轴合并后在最右侧； 2.3 合并方式-Tile(平铺) 说明：两个图公用一个X轴，Y轴各自保持不变，并入图在上方； 2.4 合并方式-Correlate(关联) 说明： 1. 主图的Y轴变成合并后的X轴，合并图的Y轴，为合并后的Y轴； 2. 合并的时候

事务命令： multi 开启事务，此时输入的命令会入队FIFO。 exec 依次执行队列中的命令，即使遇到执行错误的命令，也不会影响其他命令，redis没有事务回滚机制。 discard 放弃事务 watch CAS乐观锁，用法是在multi命令之前执行，监控某个key值，如果在命令输入完成后执行exec命令的过程中，此key被其他客户端改变，则事务拒绝执行。（REDIS_DIRTY_CAS标示被打开，exec执行前会判断此标示，如果被打开则拒绝执行） 事务的ACID性质： 原子性(Atomicity)：当前事务的所有命令都会被执行，即使是其中一个出现报错，剩余命令也会继续执行完，要么执行完，要么不执行，所以具有原子性，redis事务不具有回滚性，因为作者觉得出现单个命令出现问题是编码水平的问题，所以没必要为redis设计回滚机制。 一致性(Consistency)： 一致指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。 入队错误：redis就会拒绝执行，所以不会对一致性有影响。 执行错误：执行错误，redis在执行过程中会识别异常，数据不会被修改，所以不会影响一致性。 服务器停机：redis重启后会自动去寻找可用的RDB或者AOF来恢复数据，此时数据肯定是一致的，否则就会恢复一个空数据库，所以数据库始终是一致的。 隔离性(Isolation)：

兴起原因 Not only SQL 传统的关系性数据库 关系代数理论基础 RDBMS只能纵向扩展：通过一台服务器增加性能终究难以满足数据量增长。 严格的数据库模式 索引机制，查询优化引擎：适当量级查询效率高 事务一致性：ACID 数据完整性：主键、约束 标准化：sql标准 技术支持：商业数据库 可维护：管理员维护 关系型数据库主从模式 面对日益增长的数据量，多台服务器的写主读从，分离单台服务器压力，但效果有限，且： 集群部署配置复杂 主库压力带来延迟 扩容重新分区复杂 web2.0的需求 关系型数据库事务机制需要额外的开销，但是在Web2.0通常不要求严格的数据库事务 不需要严格的读写实时性 不包含复杂的sql查询：连接操作牺牲性能节约空间 扩充关系型数据库无法实现的特点 1.灵活的可扩展性 2.灵活的数据模型 3.与云计算紧密结合：根据负载动态伸缩集群节点 NoSQL数据库优势 1.海量数据管理需求 2.高并发需求：动态数据实时生成性能需求 3.可扩展、高可用：突发事务访问量急剧增大 NoSQL数据库劣势 缺乏底层理论基础 事务强一致性：不适用关键业务 数据模型 不同场景下需要不同的数据模型 四大类型 键值数据库 如Redis存储键值对， 适合内容缓存 简单的数据模型 频繁读写 非结构化信息同时也有一些缺点，在一些场景下是不适合的：条件查询效率低、键与键之间没有办法反应联系关系

什么是事务？ 我们在开发企业应用时，对于业务人员的一个操作实际是对数据读写的多步操作的结合。由于数据操作在顺序执行的过程中，任何一步操作都有可能发生异常，异常会导致后续操作无法完成，此时由于业务逻辑并未正确的完成，之前成功操作数据的并不可靠，需要在这种情况下进行回退。 事务的作用就是为了保证用户的每一个操作都是可靠的，事务中的每一步操作都必须成功执行，只要有发生异常就回退到事务开始未进行操作的状态。 事务管理是Spring框架中最为常用的功能之一，我们在使用Spring Boot开发应用时，大部分情况下也都需要使用事务。 快速入门 在Spring Boot中，当我们使用了spring-boot-starter-jdbc或spring-boot-starter-data-jpa依赖的时候，框 架会自动默认分别注入DataSourceTransactionManager或JpaTransactionManager。所以我们不需要任何额外 配置就可以用@Transactional注解进行事务的使用。 在该样例工程中（若对该数据访问方式不了解，可先阅读该文章），我们引入了spring-data-jpa，并创建了User实体以及对User的数据访 问对象UserRepository，在ApplicationTest类中实现了使用UserRepository进行数据读写的单元测试用例，如下：

使用@Transactional注解声明Bean底下所有业务方法需要事务管理。 1.默认一个业务方法开启和结束事务，什么时候提交，什么时候回滚呢？ Spring容器默认情况下对于运行期异常（unchecked Exception）会进行事务回滚，如果是用户违例(checked Exception),事务不会回滚。 运行期违例：throw new RuntimeException("XXX")；运行期违例不需要使用try/catch捕捉，编译可以通过 用户违例，throw new Exception("XXX");必须使用try/catch捕捉，否则编译不能通过。 也可以修改这种行为，在业务方法上加上@Transactional(rollbackFor=Exception.class),则cheked Exception也会回滚。 如果@Transactional(noRollbackFor=RuntimeException.class)，则运行期例外也不会回滚。 2.有些业务方法不需要业务管理，如获取数据的。开启事务会对性能有影响。所以使用 @Transactional(propagation=Propagation.NOT_SUPPORTED) propagation属性指定事务的传播行为。则Spring容器在该业务方法前不会开启事务。 事务的传播属性 ： （1

Spring提供了2种事务管理 编程式的 声明式的（重点）：包括xml方式、注解方式（推荐） 基于转账的demo dao层 新建包com.chy.dao，包下新建接口AccountDao、实现类AccountDaoImpl： public interface AccountDao { //查询用户账户上的余额 public double queryMoney(int id); //减少用户账户上的余额 public void reduceMoney(int id, double amount); //增加用户账户上的余额 public void addMoney(int id, double amount); } @Repository public class AccountDaoImpl extends JdbcDaoSupport implements AccountDao { @Override public double queryMoney(int id) { String sql = "select money from account_tb where id=?"; JdbcTemplate jdbcTemplate = super.getJdbcTemplate(); double money = jdbcTemplate.queryForObject(sql,