首页 >>

18道MySQL经典面试题及答案,花10分钟有不一样的收获,值得

1、MySQL的复制原理以及流程

(1)、复制基本原理流程

(PS:文末有python,java,人工智能,大数据,web前端,SQL, linux等资料免费资料)

1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中;

2. 从:io线程——在使用start slave 之后,负责从master上拉取 binlog 内容,放进 自己的relay log中;

3. 从:sql执行线程——执行relay log中的语句;

(2)、MySQL复制的线程有几个及之间的关联

MySQL 的复制是基于如下 3 个线程的交互( 多线程复制里面应该是 4 类线程):

1. Master 上面的 binlog dump 线程,该线程负责将 master 的 binlog event 传到slave;

2. Slave 上面的 IO 线程,该线程负责接收 Master 传过来的 binlog,并写入 relay log;

3. Slave 上面的 SQL 线程,该线程负责读取 relay log 并执行;

4. 如果是多线程复制,无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制, SQL 线程只做 coordinator,只负责把 relay log 中的 binlog读出来然后交给 worker 线程, woker 线程负责具体 binlog event 的执行;

(3)、MySQL如何保证复制过程中数据一致性及减少数据同步延时一致性主要有以下几个方面:

1.在 MySQL5.5 以及之前, slave 的 SQL 线程执行的 relay log 的位置只能保存在文件( relay-log.info)里面,并且该文件默认每执行 10000 次事务做一次同步到磁盘, 这意味着 slave 意外 crash 重启时, SQL 线程执行到的位置和数据库的数据是不一致的,将导致复制报错,如果不重搭复制,则有可能会

导致数据不一致。MySQL 5.6 引入参数 relay_log_info_repository,将该参数设置为 TABLE 时, MySQL 将 SQL 线程执行到的位置存到mysql.slave_relay_log_info 表,这样更新该表的位置和 SQL 线程执行的用户事务绑定成一个事务,这样 slave 意外宕机后, slave 通过 innodb 的崩溃

恢复可以把 SQL 线程执行到的位置和用户事务恢复到一致性的状态。

2.MySQL 5.6 引入 GTID 复制,每个 GTID 对应的事务在每个实例上面最多执行一次, 这极大地提高了复制的数据一致性;

3.MySQL 5.5 引入半同步复制, 用户安装半同步复制插件并且开启参数后,设置超时时间,可保证在超时时间内如果 binlog 不传到 slave 上面,那么用户提交事务时不会返回,直到超时后切成异步复制,但是如果切成异步之前用户线程提交时在 master 上面等待的时候,事务已经提交,该事务对 master

上面的其他 session 是可见的,如果这时 master 宕机,那么到 slave 上面该事务又不可见了,该问题直到 5.7 才解决;

4.MySQL 5.7 引入无损半同步复制,引入参 rpl_semi_sync_master_wait_point,该参数默认为 after_sync,指的是在切成半同步之前,事务不提交,而是接收到 slave 的 ACK 确认之后才提交该事务,从此,复制真正可以做到无损的了。

5.可以再说一下 5.7 的无损复制情况下, master 意外宕机,重启后发现有 binlog没传到 slave 上面,这部分 binlog 怎么办???分 2 种情况讨论, 1 宕机时已经切成异步了, 2 是宕机时还没切成异步???这个怎么判断宕机时有没有切成异步呢???分别怎么处理???

延时性:

5.5 是单线程复制, 5.6 是多库复制(对于单库或者单表的并发操作是没用的), 5.7 是真正意义的多线程复制,它的原理是基于 group commit, 只要

master 上面的事务是 group commit 的,那 slave 上面也可以通过多个 worker线程去并发执行。和 MairaDB10.0.0.5 引入多线程复制的原理基本一样。

(4)、工作遇到的复制 bug 的解决方法

5.6 的多库复制有时候自己会停止,我们写了一个脚本重新 start slave;待补充…

2、MySQL中myisam与innodb的区别,至少5点

(1)、问5点不同

1.InnoDB支持事物,而MyISAM不支持事物

2.InnoDB支持行级锁,而MyISAM支持表级锁

3.InnoDB支持MVCC, 而MyISAM不支持

4.InnoDB支持外键,而MyISAM不支持

5.InnoDB不支持全文索引,而MyISAM支持。

6.InnoDB不能通过直接拷贝表文件的方法拷贝表到另外一台机器, myisam 支持

7.InnoDB表支持多种行格式, myisam 不支持

8.InnoDB是索引组织表, myisam 是堆表

(2)、innodb引擎的4大特性

1.插入缓冲(insert buffer)

2.二次写(double write)

3.自适应哈希索引(ahi)

4.预读(read ahead)

(3)、各种不同 mysql 版本的Innodb的改进

MySQL5.6 下 Innodb 引擎的主要改进:

(1) online DDL

(2) memcached NoSQL 接口

(3) transportable tablespace( alter table discard/import tablespace)

(4) MySQL 正常关闭时,可以 dump 出 buffer pool 的( space, page_no),重启时 reload,加快预热速度

(5)索引和表的统计信息持久化到 mysql.innodb_table_stats 和mysql.innodb_index_stats,可提供稳定的执行计划

(6)Compressed row format 支持压缩表

MySQL 5.7 innodb 引擎主要改进

(1) 修改 varchar 字段长度有时可以使用 online DDL

(2) Buffer pool 支持在线改变大小

(3) Buffer pool 支持导出部分比例

(4) 支持新建 innodb tablespace,并可以在其中创建多张表

(5) 磁盘临时表采用 innodb 存储,并且存储在 innodb temp tablespace 里面,以前是 myisam 存储

(6) 透明表空间压缩功能

(4)、2者select count(*)哪个更快,为什么

myisam更快,因为myisam内部维护了一个计数器,可以直接调取。

(5)、2 者的索引的实现方式

都是 B+树索引, Innodb 是索引组织表, myisam 是堆表, 索引组织表和堆表的区别要熟悉3、MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义(1)、varchar与char的区别

在单字节字符集下, char(N) 在内部存储的时候总是定长, 而且没有变长字段长度列表中。在多字节字符集下面, char(N)如果存储的字节数超过 N,那么 char(N)将和 varchar(N)没有区别。在多字节字符集下面,如果存

储的字节数少于 N,那么存储 N 个字节,后面补空格,补到 N 字节长度。都存储变长的数据和变长字段长度列表。varchar(N)无论是什么字节字符集,都是变长的,即都存储变长数据和变长字段长度列表。

(2)、varchar(50)中50的涵义

最多存放50个字符,varchar(50)和(200)存储hello所占空间一样,但后者在排序时会消耗更多内存,因为order by col采用fixed_length计算col长度(memory引擎也一样)。在早期 MySQL 版本中, 50 代表字节数,现在代表字符数。

(3)、int(20)中20的涵义

是指显示字符的长度

不影响内部存储,只是影响带 zerofill 定义的 int 时,前面补多少个 0,易于报表展示

(4)、mysql为什么这么设计

对大多数应用没有意义,只是规定一些工具用来显示字符的个数;int(1)和int(20)存储和计算均一样;4、innodb的事务与日志的实现方式

(1)、有多少种日志

redo和undo

(2)、日志的存放形式

redo:在页修改的时候,先写到 redo log buffer 里面, 然后写到 redo log 的文件系统缓存里面(fwrite),然后再同步到磁盘文件( fsync)。

Undo:在 MySQL5.5 之前, undo 只能存放在 ibdata*文件里面, 5.6 之后,可以通过设置 innodb_undo_tablespaces 参数把 undo log 存放在 ibdata*之外。

(3)、事务是如何通过日志来实现的,说得越深入越好基本流程如下:

因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的

状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。

5、MySQL binlog的几种日志录入格式以及区别

(1)、 各种日志格式的涵义1.Statement:每一条会修改数据的sql都会记录在binlog中。

优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO,提高性能。(相比row能节约多少性能 与日志量,这个取决于应用的SQL情况,正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量,

但是考虑到如果带条 件的update操作,以及整表删除,alter表等操作,ROW格式会产生大量日志,因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况,其所 产生的日志量会增加多少,以及带来的IO性能问题。)

缺点:由于记录的只是执行语句,为了这些语句能在slave上正确运行,因此还必须记录每条语句在执行的时候的 一些相关信息,以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,

像一些特定函数功能,slave可与master上要保持一致会有很多相关问题(如sleep()函数, last_insert_id(),以及user-defined functions(udf)会出现问题).

从全库备份中抽取出t表的表结构

# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `t`/!d;q' dump.sql

DROP TABLE IF EXISTS`t`;

/*!40101 SET@saved_cs_client =@@character_set_client */;

/*!40101 SETcharacter_set_client = utf8 */;

CREATE TABLE `t` (

`id` int(10) NOT NULL AUTO_INCREMENT,

`age` tinyint(4) NOT NULL DEFAULT '0',

`name` varchar(30) NOT NULL DEFAULT '',

PRIMARY KEY (`id`)

) ENGINE=InnoDBAUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

/*!40101 SETcharacter_set_client = @saved_cs_client */;

从全库备份中抽取出t表的内容

# grep'INSERT INTO `t`' dump.sql

INSERT INTO `t`VALUES (0,0,''),(1,0,'aa'),(2,0,'bbb'),(3,25,'helei');

17、在当前的工作中,你碰到到的最大的 mysql db 问题以及如何解决的?

可以选择一个处理过的比较棘手的案例,或者选择一个老师在课程上讲过的死锁的案例;没有及时 Purge + insert 唯一索引造成的死锁:具体案例可以参考学委笔记。18、请简洁地描述下 MySQL 中 InnoDB 支持的四种事务隔离级别名称,以及逐级之间的区别?

(1)、事物的4种隔离级别

读未提交(read uncommitted)

读已提交(read committed)

可重复读(repeatable read)

串行(serializable)

(2)、不同级别的现象

Read Uncommitted:可以读取其他 session 未提交的脏数据。

Read Committed:允许不可重复读取,但不允许脏读取。提交后,其他会话可以看到提交的数据。

Repeatable Read: 禁止不可重复读取和脏读取、以及幻读(innodb 独有)。

Serializable: 事务只能一个接着一个地执行,但不能并发执行。事务隔离级别最高。

不同的隔离级别有不同的现象,并有不同的锁定/并发机制,隔离级别越高,数据库的并发性就越差。

最后有小伙伴需要:

python,java,人工智能,大数据,web前端,SQL, linux等资料教程的话,来私信小编“资料”通通免费送你!

附一部分资料截图:

来私信小编“资料”免费领取吧!

文章来源:六合开奖

标签:香港金多宝资料大全,二四六天天好彩资料大全,246免费资料大全 天下,二四六天天好彩玄机图,管家婆开奖