目录
12.事务的特性是什么?可以详细说一下吗?
回答
13并发事务带来哪些问题?怎么解决这些问题呢?MySQL的默认隔离级别是?
脏读:一个事务读到另外一个事务还没有提交的数据。
不可重复读:一个事务先后读取同一条记录,但两次读取的数据不同,称之为不可重复读。
幻读:一个事务按照条件查询数据时,没有对应的数据行,但是在插入数据时,又发现这行数据已经存在,好像出现已经存在,好像出现了”幻影”。幻读是在解决不可重复读的基础上
编辑
怎么解决并发事务的问题呢?
编辑
回答
15.undo log和redo log的区别
redo log
undo log
回答
16.事务中的隔离性是如何保证的呢?
回答
17.解释一下MVCC
17.1记录中的隐藏字段
17.2undo log
17.3readview
17.3.1当前读
17.3.2快照读
回答
18.MySQL主从同步原理
回答
19.你们项目用过分库分表吗
19.1拆分策略
19.1.1垂直拆分
19.1.2水平拆分
19.1.3分库分表的策略有哪些
回答
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