近期java面试总结-mysql(持续更新)

目录

1.mysql几种常用日志作用

2.mysql buff poll的作用

3.你项目中什么时候会用到索引 

 4.主从复制 会不会出现从库有数据主库没有

5.主从复制原理

6.mysql怎样解决幻读的 

1.mysql几种常用日志作用

记下面三个即可。有时候容易记混，redo 重做，undo 回滚，bin log 二进制

bin log：记载常用ddl、dml语句，用于主从复制，主从同步；

redo log：重做日志，确保日志持久性，防止在发生故障时，脏页未写入磁盘。重启数据库会对redo log 进行重做，达到事务一致性；

undo log:回滚，保证数据的原子性，记录事务发生之前的一个版本，用于回滚；innodb事务可重复读和读取已提交 隔离级别就是通过mvcc+undo实现；

2.mysql buff poll的作用

简单回答几句

默认大小128m；一块连续的内存空间

缓冲池， 减少每次查询与磁盘的交互；

数据库操作的时候，会把磁盘数据加载到缓冲区，这样不直接与磁盘打交道；

每个缓冲页得大小时16kb，所以缓存区得大小肯定时越大越好

缓冲页和磁盘的数据页是对应的都是16kb

几个特殊词：

脏页：经过数据操作，缓冲区的数据与磁盘不一致，需要将脏页刷到磁盘；

预读：数据不是一条一条读的，是一页一页加载到缓冲区的

预读失效：预读的数据没有被使用

3.你项目中什么时候会用到索引 

这是一个简单又复杂的问题explain

经常查询的字段

常用作表连接的字段

重复度高的不易作为索引

单表索引建议不超过3个

 顺便讲下聚簇索引和非聚簇索引的区别

聚簇索引：一般会把主键或者唯一索引、隐藏键rowid作为一个表的聚簇索引

聚簇索引和数据存放在一起作为叶子节点

回表：就是根据普通索引拿到聚簇索引值，再进行一次查找拿到最终数据

 4.主从复制 会不会出现从库有数据主库没有

innodb_flush_log_at_trx_commit 设置为1时，commit 完成必然写入了硬盘。如果为了提升性能改为了0或2，那么数据库或系统故障时是有可能丢失1s数据的。1s有多少数据很难估算，如果业务繁忙可能是上千，上万或更多。

双1 的另一个参数sync_binlog对应的则是事务数，为了数据安全我们通常也设定为1，但是如果为了提升主库性能并且要保证从库复制的正常，我们可能会考虑改大该值，1000，2000 或更多，相应的从库也有丢失这么多数据的可能。

这样，如果参数innodb_flush_log_at_trx_commit设置为0, sync_binlog 设置为2000. 系统崩溃前的最后1s内执行了7000条插入。那么可能遇到的情况就是主库丢失了7000条数据，而从库只丢失了1000条数据。虽然每条数据主库都自动提交了，但是主库却还没来得及把redo log buffer中的内容刷入到硬盘，系统就崩了，重启后内存数据自然全部丢失，而binlog cache中的数据则每2000条就刷一次到硬盘，所以只损失了最后1000条。

复制分为：异步复制和半同步复制

1.异步复制：主库发出commit命令，通知从库dump线程获取binlog日志，然后主库完成提交，不关心从库是否取了日志。

所以从库有没有获取到binlog，没人知道。

2.半同步复制-after_commit
主库发出commit，通知从库dump线程获取binlog日志，主库后台完成提交，但当前会话需等待从库接收完日志返回ACK（其他会话可以看到已变更的数据，但当前会话不能做任何操作，尚需等待ACK返回）。从库返回ACK则当前会话完成提交返回操作符。

可能的问题：从库还没写或没接收完binlog主从就异常了。但主库后台已经完成了提交。主库比从库多数据（主库已提交，从库缺失binlog）。

3.半同步复制-after_sync
主库发出commit，同时通知从库dump线程获取binlog日志，主库等待从库接收完日志返回ACK，从库返回则主库完成提交返回操作符，否则继续等待。

从库没写完，主库不会完成提交，所以主库不可能比从库多数据。但是极端情况下可能出现从库完成了binlog落盘，返回ACK给主库的时候主从异常了。导致的问题：从库比主库多数据（从库已接收binlog，但主库没得到ACK，所以没提交，事务进行了回滚。）这时可能导致的问题：1.从库比主库多数据；2.主库重新提交时，从库发生数据冲突。

3不能完全保证数据不丢失后，但3出现的概率要比2小得多

5.主从复制原理

步骤一：主库的更新事件(update、insert、delete)被写到 binlog

步骤二：从库发起连接，连接到主库。

步骤三：此时主库创建一个 binlog dump thread，把 binlog 的内容发送到从库。

步骤四：从库启动之后，创建一个 I/O 线程，读取主库传过来的binlog 内容并写入到 relay log

步骤五：还会创建一个 SQL 线程，从 relay log 里面读取内容，从Exec_Master_Log_Pos 位置开始

执行读取到的更新事件，将更新内容写入到slave 的 db

6.mysql怎样解决幻读的 

在RR(也就是可重复读)的事务隔离级别下，InnoDB采用了MVCC机制来解决幻读问题。

MVCC就是一种乐观锁的机制，它通过对不同事务生成不同的快照版本，通过UNDO版本链进行管

理并且在MVCC里面，规定了高版本能够看到低版本的事务变更，低版本看不到高版本的事务变更从 而实现了不同事务之间的数据隔离，解决了幻读的问题。

但是在当前读的情况下，是直接读取内存的数据，跳过了快照度，所以还是会出现幻读问题。

我认为可以通过两个方式来解决。

第一种是尽量避免当前读的情况

第二种是引入LBCC的方式 

用LBCC也就是基于锁的机制来解决，也就是常说的行锁、表锁、间隙锁

等