运维面试必问的MySQL高频面试题（2021年最新版）

前言

网上的运维面试题文章有非常多，在我的博客中也有一些是这些年运维人员面试的面试题，之前一些经典的面试题我已经整理到专栏《运维面试宝典》里，这个专栏里的面试技巧可以说永远不会过时，而且我会每隔一段时间进行补充和优化。

从一开始开专栏《运维面试宝典》的时候，规划是10篇文章，现在已经更新了55篇文章，后续还会增加。

现在网上很多题目早已不是当前的热门题目，没有必要在这些题目上花太多时间。

很多答案放现在已经不准确，可能会误导新人。

因此，我花了几天时间整理了一些时下高频的 Linux运维面试题，并反复斟酌，给出符合当前版本的解析。

这部分内容会收录在专栏《我要进大厂》，适合所有有工作经验的小伙伴和应届毕业参加校招的小伙伴。

面试系列

这些年我一直在面试一线，帮助小伙伴辅导面试准备及面试复盘，拿到过大大小小的offer，比如阿里，字节，美团，快手，百度等等
每次面试后我都会将面试的题目进行记录，并整理成自己的题库，最近我将这些题目整理出来，并按大厂的标准给出自己的解析，希望在这金三银四的季节里，能助你一臂之力。

注意： 本文针对的是MySQL 运维岗位的面试题

正文

1. drop，delete和truncate删除数据的区别？

• delete 语句执行删除是每次从表中删除一行，并且同时将改行的删除操作作为事务记录在日志中保存以便进行回滚。
• truncate 则是一次从表中删除所有的数据并不把单独的删除操作记录计入日志，删除行是不能恢复的。执行速度很快
• drop 是将表所占的空间全部释放掉。
  在删除速度上， drop>truncate>delete
  想要删除部分数据用delete，想要删除表用drop。 想保留表但是把数据删除，如果和事务无关用truncate

2. MySQL主从原理

从库生成两个线程，一个I/O线程，一个SQL线程；

i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log(中继日志) 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；

SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

3. MySQL主从复制存在哪些问题？

mysql主从复制存在的问题：主库宕机后，数据可能丢失，从库只有一个sql Thread，主库写压力大，复制很可能延时。

解决方法： 用半同步复制解决数据丢失的问题
用并行复制解决从库复制延迟的问题。

4. MySQL复制的方法

级联复制：将主库的数据同步到级联库，然后级联库把自己的数据同步到从库上，这样可以减少主库的压力

半同步复制：
默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当主库或从库发生故障时，有可能从库没有接收到主库发送过来的binlog日志，这就会造成主库和从库的数据不一致，甚至在恢复时造成数据的丢失。

在开启了半同步复制机制后，主库只有当有任意一台从库已经接收到主库的数据后，告诉主库。主库收到从库同步成功的信息后，才继续后面的操作。

5. 主从延迟产生的原因及解决方案？

• 主库的并发比较高的时候，产生的DDL数量超过了从库的一个sql线程所承受的范围，那么延时就产生了。
• 还有可能是与从库的大型query语句产生的了锁等待 。
• 网络抖动

解决方案：
1)、架构方面

1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。

2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。

3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。

4.不同业务的mysql物理上放在不同机器，分散压力。

5.使用比主库更好的硬件设备作为slave总结，mysql压力小，延迟自然会变小。

2)、mysql主从同步加速

1、sync_binlog在slave端设置为0

2、–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

3、直接禁用slave端的binlog

6. 判断主从延迟的方法

可以通过命令 show slave status 查看

比如通过seconds_behind_master的值来判断
NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.
0 - 该值为零，是我们极为渴望看到的情况，表示主从复制状态正常

7. MySQL忘记root密码如何找回

1. 在配置文件里加上skip-grant-tables ，重启MySQL
2. 使用MySQL-uroot -p 进入
3. 使用update 修改密码

mysql> USE mysql ;
mysql> UPDATE user SET Password = password ( &＃39;new-password&＃39; ) WHERE User = &＃39;root&＃39; ;


8. MySQL的数据备份方式

工具一 MySQLdump工具备份
工具二： xtrabackup工具备份

备份分为：冷备，温备和热备

根据要备份的数据集合又分为： 完全备份，增量备份和差异备份

需要备份的对象：

• 数据
• 配置文件
• OS相关的配置文件
• 代码： 存储过程，存储函数和处罚器
• 复制相关的配置
• 二进制日志

数据量比较大的时候用xtrabackup

基于MySQLdump做备份策略： 周日做全备，备份同时滚动日志
周一到周六：备份二进制文件

恢复的时候： 完全备份+二进制文件中到此处的事件

xtrabackup的特点：

1) 备份过程快速、可靠；2) 备份过程不会打断正在执行的事务；3) 能够基于压缩等功能节约磁盘空间和流量；4) 自动实现备份检验；5) 还原速度快；


逻辑备份： 类似于select * from 查询满足条件的备份
物理本分： 备份文件+日志文件
所以xtrabackup就是物理备份
MySQLdump就是逻辑备份

9. innodb的特性

一：插入缓冲

二：二次写

三：自适应哈希

四：预读

10. varchar(100) 和varchar(200）的区别

varchar(100)最多存放100个字符，varchar(200)最多存放200个字符，varchar(100)和(200)存储hello所占空间一样，但后者在排序时会消耗更多内存，因为order by col采用fixed_length计算col长度(memory引擎也一样

11. MySQL主要的索引类型

普通索引：是最基本的索引，它没有任何限制；

唯一索引：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一；

主键索引：是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值；

组合索引：指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合；

全文索引：主要用来查找文本中的关键字，而不是直接与索引中的值相比较，mysql中MyISAM支持全文索引而InnoDB不支持；

12. 请说出非关系型数据库的典型产品、特点及应用场景？

MongoDB
特点：1.高性能，易部署，易使用。
2.面向集合存储，易存储对象类型的数据。
3.模式自由
4.自动处理碎片，以支持云计算层次的扩展性。
应用场景：
网站数据：mongodb非常适合实时的插入，更新与查询。
缓存：适合作为信息基础设施的缓存层
大尺寸、低价值的数据
高伸缩性的场景
Redis
特点：1.性能极高，能支持超过100k+每秒的读写频率
2.丰富的数据类型
3.所有操作都是原子性的
使用场景：
少量的数据存储，高速读写访问
SQLlite
特点：
1.嵌入式的，零配置，无需安装和管理配置
2.ACID事务
3.存储在单一磁盘文件中的一个完整的数据库。
应用场景：
1.需要数据库的小型桌面软件。
2.需要数据库的手机软件。
3.作为数据容器的应用场景。

13. 如何加强MySQL安全，请给出可行的具体措施？

1.避免直接从互联网访问mysql数据库，确保特定主机才拥有访问权限。
2.定期备份数据库
3.禁用或限制远程访问
在my.cnf文件里设置bind-address指定ip
4.移除test数据库（默认匿名用户可以访问test数据库）
5.禁用local infile
mysql> select load_file("/etc/passwd");
在my.cnf里[mysqld]下添加set-variable=local-infile=0
6.移除匿名账户和废弃的账户
7.限制mysql数据库用户的权限
8.移除和禁用.mysql_history文件

14. Binlog工作模式有哪些？各什么特点，企业如何选择？

1.row level行级模式
优点：记录数据详细（每行），主从一致
缺点：占用大量的磁盘空间，降低了磁盘的性能
2.statement level模式（默认）
优点：记录的简单，内容少 ，节约了IO，提高性能 缺点：导致主从不一致
3.MIXED混合模式
结合了statement和row模式的优点，会根据执行的每一条具体的SQL语句来区分对待记录的日志形式。对于函数，触发器，存储过程会自动使用row level模式
企业场景选择：
1.互联网公司使用mysql的功能较少（不用存储过程、触发器、函数），选择默认的statement模式。
2.用到mysql的特殊功能（存储过程、触发器、函数）则选则MIXED模式
3.用到mysql的特殊功能（存储过程、触发器、函数），有希望数据最大化一致则选择row模式。

15. 生产一主多从从库宕机，如何手工恢复？

处理方法：重做slave

1. 停止slave


2. 导入备份数据


3. 配置master.info信息


4. 启动slave


5. 检查从库状态


16. MySQL中MyISAM与InnoDB的区别，至少5点

a. InnoDB支持事务，而MyISAM不支持事务。
b. InnoDB支持行级锁，而MyISAM支持表级锁
c. InnoDB支持MVCC，而MyISAM不支持
d. InnoDB支持外键，而MyISAM不支持
e. InnoDB不支持全文索引，而MyISAM支持

17. 网站打开慢，请给出排查方法，如是数据库慢导致，如何排查并解决，请分析并举例？

1. 检查操作系统是否负载过高


2. 登陆mysql查看有哪些sql语句占用时间过长，show processlist;


3. 用explain查看消耗时间过长的SQL语句是否走了索引


4. 对SQL语句优化，建立索引


18. xtrabackup的备份，增量备份及恢复的工作原理

XtraBackup基于InnoDB的crash-recovery功能，它会复制InnoDB的data file，由于不锁表，复制出来的数据是不一致的，在恢复的时候使用crash-recovery，使得数据恢复一致。
InnoDB维护了一个redo log，又称为transaction log（事务日志），它包含了InnoDB数据的所有改动情况。当InnoDB启动的时候，它会先去检查data file和transaction log，并且会做两步操作：
XtraBackup在备份的时候，一页一页的复制InnoDB的数据，而且不锁定表，与此同时，XtraBackup还有另外一个线程监视着transaction log，一旦log发生变化，就把变化过的log pages复制走。为什么要着急复制走呢？因为transaction log文件大小有限，写满之后，就会从头再开始写，所以新数据可能会覆盖到旧的数据。
在prepare过程中，XtraBackup使用复制到的transaction log对备份出来的InnoDB data file进行crash recover

19.误执行drop数据，如何通过xtrabackup恢复？

1. 关闭mysql服务


2. 移除mysql的data目录及数据


3. 将备份的数据恢复到mysql的data目录


4. 启动mysql服务


20. 如何做主从数据一致性校验？

主从一致性校验有多种工具 例如checksum、mysqldiff、pt-table-checksum等

21. MySQL有多少日志

错误日志：记录出错信息，也记录一些警告信息或者正确的信息。

查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。

慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。

二进制日志：记录对数据库执行更改的所有操作。

中继日志。

事务日志。
le/details/111957929

22. MySQL binlog的几种日志录入格式以及区别

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)会出现问题).
使用以下函数的语句也无法被复制：

• LOAD_FILE()
• UUID()
• USER()
• FOUND_ROWS()
• SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
  同时在INSERT …SELECT 会产生比 RBR 更多的行级锁

2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。

23. MySQL数据库cpu飙升到500%的话他怎么处理？

当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理

如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，
看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。

一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。

也有可能是每个 sql 消耗资源并不多，但是突然之间，
有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等

最后

金三银四的季节，相信有不少同学正准备跳槽。

近期我会对运维的高频问题进行整理汇总，对每个题目解析时都会按较高的标准进行深入剖析，有很多是去大公司面试的面试真题，可能只看一遍并不能完全明白，但是相信反复阅读，定能有所收获。

原创不易，如果你觉得本文写的还不错，对你有帮助，请通过【点赞】让我知道，支持我写出更好的文章