目录
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也就是基于锁的机制来解决,也就是常说的行锁、表锁、间隙锁等