目录
13并发事务带来哪些问题？怎么解决这些问题呢？MySQL的默认隔离级别是？
不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。
幻读：一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现已经存在，好像出现了”幻影”。幻读是在解决不可重复读的基础上
12.事务的特性是什么？可以详细说一下吗？
事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。
ACID是什么？可以详细说一下吗？
- 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
- 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
- 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
- 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。
回答
- 原子性( Atomicity )
- 一致性( Consistency )
- 隔离性( Isolation )
- 持久性( Durability )
13并发事务带来哪些问题？怎么解决这些问题呢？MySQL的默认隔离级别是？
并发事务问题：脏读、不可重复读、幻读
隔离级别：读未提交、读已提交、可重复读、串行化
| 问题 | 描述 |
| 脏读 | 一个事务读到另外一个事务还没有提交的数据。 |
| 不可重复读 | 一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。 |
| 幻读 | 一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现已经存在，好像出现了”幻影”。 |
脏读：一个事务读到另外一个事务还没有提交的数据。
不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。
幻读：一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现已经存在，好像出现了”幻影”。幻读是在解决不可重复读的基础上
怎么解决并发事务的问题呢？
解决方案：对事物进行隔离
回答
并发事务的问题：
- 脏读：一个事务读到另外一个事务还没有提交的数据。
- 不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同
- 幻读：一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了”幻影”。
隔离级别：
- READ UNCOMMITTED 未提交读 ------脏读、不可重复读、幻读（解决不了的）
- READ COMMITTED 读已提交 ------不可重复读、幻读（解决不了的）
- REPEATABLE READ 可重复读 -------幻读（解决不了的）
- SERIALIZABLE
- 串行化
15.undo log和redo log的区别
缓冲池（buffer pool）:主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度
数据页（page）:是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。页中存储的是行数据
磁盘结构中主要存储的就是数据页，当我们操作数据的时候，并不会直接操作磁盘，首先先操作内存（缓冲池），看看有没有需要操作的数据，没有的话，就会从磁盘中把数据加载到内存中，操作完成后，会按照一定的频率再把数据同步到磁盘中，就可以减少磁盘的io，加快处理的速度
redo log
重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log file）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用。
当有增删改查的时候，现在BufferPool中发生改变，RedoLogBuffer就会记录数据页的变化，一但RedoLogBuffer发生变化，就会同步加载到磁盘文件中RedoLogFile中，如果对当页数据同步失败了，就会从RedoLogFile恢复数据
刷新当页数据的到磁盘的加入发生了错误，就可以使用Redo Log来进行数据的恢复
undo log
回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚 和 MVCC(多版本并发控制) 。undo log和redo log记录物理日志不一样，它是逻辑日志。
- 可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，
- 当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
undo log可以实现事务的一致性和原子性
回答
redo log: 记录的是数据页的物理变化，服务宕机可用来同步数据
undo log ：记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据
redo log保证了事务的持久性，undo log保证了事务的原子性和一致性
16.事务中的隔离性是如何保证的呢？
回答
锁：排他锁（如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁）
mvcc : 多版本并发控制
17.解释一下MVCC
全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突
MVCC的具体实现，主要依赖于数据库记录中的隐式字段、undo log日志、readView。
17.1记录中的隐藏字段
| 隐藏字段 | 含义 |
| DB_TRX_ID | 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。 |
| DB_ROLL_PTR | 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。 |
| DB_ROW_ID | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。 |
17.2undo log
回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，mvcc版本访问也需要，不会立即被删除。
17.3readview
ReadView（读视图是快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id
17.3.1当前读
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：
select..．lock in share mode(共享锁)，select..．for update、update、insert、delete(排他锁)都是一种当前读。
17.3.2快照读
简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
- Read Committed：每次select，都生成一个快照读。
- Repeatable Read：开启事务后第一个select语句才是快照读的地方。
ReadView中包含了四个核心字段：
| 字段 | 含义 |
| m_ids | 当前活跃的事务ID集合 |
| min_trx_id | 最小活跃事务ID |
| max_trx_id | 预分配事务ID，当前最大事务ID+1（因为事务ID是自增的） |
| creator_trx_id | ReadView创建者的事务ID |
不同的隔离级别，生成ReadView的时机不同：
READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。
回答
MySQL中的多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突
1.隐藏字段：
- trx_id(事务id)，记录每一次操作的事务id，是自增的
- roll_pointer(回滚指针)，指向上一个版本的事务版本记录地址
2.undo log：
- 回滚日志，存储老版本数据
- 版本链：多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll_pointer指针形成一个链表
3.readView解决的是一个事务查询选择版本的问题
- 根据readView的匹配规则和当前的一些事务id判断该访问那个版本的数据
- 不同的隔离级别快照读是不一样的，最终的访问的结果不一样 RC ：每一次执行快照读时生成ReadView RR：仅在事务中第一次执行快照读时生成ReadView，后续复用
18.MySQL主从同步原理
MySQL主从复制的核心就是二进制日志
二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。
回答
MySQL主从复制的核心就是二进制日志binlog(DDL（数据定义语言）语句和 DML（数据操纵语言）语句)
- 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
- 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
- 从库重做中继日志中的事件，将改变反映它自己的数据
19.你们项目用过分库分表吗
分担访问压力
解决存储压力
分库分表的时机：
1，前提，项目业务数据逐渐增多，或业务发展比较迅速
2，优化已解决不了性能问题（主从读写分离、查询索引…）
3，IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）
19.1拆分策略
19.1.1垂直拆分
垂直分库
以表为依据，根据业务将不同表拆分到不同库中。
特点： 1.按业务对数据分级管理、维护、监控、扩展
2.在高并发下，提高磁盘IO和数据量连接数
垂直分表
垂直分表：以字段为依据，根据字段属性将不同字段拆分到不同表中。
特点： 1，冷热数据分离
2，减少IO过渡争抢，两表互不影响
19.1.2水平拆分
水平分库
路由规则:1.根据id节点取模
2.按id也就是范围路由，节点1(1-100万 ),节点2(100万-200万)
3.…
水平分库：将一个库的数据拆分到多个库中。
特点：1. 解决了单库大数量，高并发的性能瓶颈问题
2.提高了系统的稳定性和可用性
水平分表
水平分表：将一个表的数据拆分到多个表中(可以在同一个库内)。
特点：1.优化单一表数据量过大而产生的性能问题;
2.避免IO争抢并减少锁表的几率;
19.1.3分库分表的策略有哪些
新的问题和新的技术
- 分库之后的问题：
- 分布式事务一致性问题
- 跨节点关联查询
- 跨节点分页、排序函数
- 主键避重
分库分表中间件：
- sharding-sphere
- mycat
回答
业务介绍：
1，根据自己简历上的项目，想一个数据量较大业务（请求数多或业务累积大）
具体拆分策略：
1，水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题
2，水平分表，解决单表存储和性能的问题
3，垂直分库，根据业务进行拆分，高并发下提高磁盘IO和网络连接数----微服务一般用的多
4，垂直分表，冷热数据分离，多表互不影响2----用的也多
注意：水平分库，水平分表要使用中间件：sharding-sphere、mycat
扫一扫
2887
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
