一、关于写一两年MySQL DBA 经验
 大部分MySQL应聘的简历当中，其中许多有水分，一看到简历自我介绍，说公司项目的时候，会写上 linux 系统维护，mssql server 项目，或者 oracle data gard 项目，一般如果有这些的话，工作在 3 年到 4年的话，他的 2 年 MySQL DBA 管理经验，是有很大的水分的。
这些同学一般很多人卡在基础知识这一环节之上，比如：
（ 1）有的卡在复制原理之上
（ 2）有的卡在 binlog 的日志格式的种类和分别
（ 3）有的卡在 innodb 事务与日志的实现上。
（ 4）有的卡在 innodb 与 myisam 的索引实现方式的理解上面。
个人觉得如果有过真正的 2 年 mysql 专职 dba 经验，那么肯定会在 mysql 的基本原理上有所研究，因为很多问题都不得不让你去仔细研究各种细节，而自 己研究过的细节肯定会记忆深刻，别人问起一定会说的头头是道，起码一些最基本的关键参数比如
Seconds_Behind_Master 为 60 这个值 60 的准确涵义，很多mysql dba，没有一个说的准确，有的说不知道忘记了，有的说是差了 60 秒，有的说是与主上执行时间延后了 60 秒。
这个参数在风哥MySQL教程中已经讲过：Seconds_Behind_Master：一般意义上说代表着从库和主库的延迟时间，数值越高意味着延迟越大，但是当Seconds_Behind_Master为0的时候，并不真正意味着从库已经追上主库了。相信大家都遇到过，从监控图上看，Seconds_Behind_Master一直都是0，在某一个时间点之后突然就变得非常高。这是由于在主库上执行了一个非常大的event，在这个event在主库上没执行完毕的时候，从库的Seconds_Behind_Master会显示为0，而当主库执行完毕传到从库上开始执行的时候，就会显示Seconds_Behind_Master非常巨大了。官方的文档解释如下：
It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately. When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0; but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event. This is especially likely when the events have old timestamps; in such cases, if you execute SHOW SLAVE STATUS several times in a relatively short period, you may see this value change back and forth repeatedly between 0 and a relatively large value.

那么这个seconds_behind_master的值到底是怎么计算出来的呢？官方的解释如下：
Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the master binary log。
也就是说，是SQL thread在执行IO thread dump下来的relay log的时间差。大家都知道relay log中event记录的时间戳是主库上的时间戳，而SQL thread的时间戳是从库上的，也就是说，如果主库和从库的时间是一致的，那么这个SBM代表的确实是从库延后主库的一个时间差。但是如果主库和从库的时间不是一致的，那么这个Seconds_Behind_Master的意义就基本不存在了

二、对于简历中写有熟悉 mysql 高可用方案
我一般先问他现在管理的数据库架构是什么，如果他只说出了主从，而没有说任何 ha的方案，那么我就可以判断出他没有实际的 ha 经验。不过这时候也不能就是 断定他不懂mysql 高可用，也许是没有实际机会去使用，那么我就要问 mmm 以及 mha 以及mm+keepalived 等的原理
实现方式以及它们之间的优 势和不足了，一般这种情况下，能说出这个的基本没有。
mmm 那东西好像不靠谱，据说不稳定，但是有人在用的，我只在虚拟机上面用过，和mysql-router 比较像，都是指定可写的机器和只读机器。 MHA 的话一句话说不完。
 在风哥MySQL学习教程中的第6阶段讲了关于各种MySQL高可用架构和方案，大家可以参加。

三、 关于熟悉 mysql 集群的
(1) 分布式数据库产品的特点（至少写4条）
数据分布在多个异地点，抗灾性强
并发性高
受网络影响很大
单机的性能不是特别重要，但是总体成本很高。
扩展性强

(2) 数据拆分架构的优缺点（至少写8条）
透明性，程序不需要做任何修改
解决集中数据库的扩展局限性。实现水平扩展问题，涉及到数据的拆分问题
提高数据库服务的性能、可靠性、可用性
实现技术不难，开发成本和维护成本可控
测试成本高
无法支持分布式事务
数据拆分后数据合并难
部分功能限制
扩展受限

四、 关于有丰富的备份经验的
就问 mysqldump 中备份出来的 sql，如果我想 sql 文件中，一行只有一个 insert .... value()的话，怎么办？如果备份需要带上 master 的复制点信息怎么办？或者 xtrabackup 中如何
做到实时在线备份的？以及 xtrabackup 是如何做到带上 master 的复制点的信息的？ 当前 xtrabackup 做增量备份的时候有何缺陷？能全部回答出来的没有一个，不过没有关系，只要回答出 mysqldump 或者xtrabackup 其中一个的也可以。
1). --skip-extended-insert
2). --master-date=1
3). 因为 xtrabackup 是多线程，一个线程不停地在拷贝新产生的 redo 文件，另外的线程去备份数据库，当所有表空间备份完成的时候，它会执行 flush table with read lock 操作
锁住所有表，然后执行 show master status; 接着执行 flush engine logs; 最后解锁表。执行 show master status; 时就能获取到 mster 的复制点信息，执行 flush engine logs 强制把redo 文件刷新到磁盘。
4). xtrabackup 增量备份的缺陷不了解，在线上用 xtrabackup 备份没有发现什么缺陷。

五、关于有丰富的线上恢复经验的
就问你现在线上数据量有多大，如果是 100G，你用 mysqldump 出来要多久，然后 mysql进去又要多久，如果互联网不允许延时的话，你又怎么做到 恢复单张表的时候保证 nagios不报警。如果有人说 mysqldump 出来 1 个小时就 ok 了，那么我就要问问他 db 服务器是
啥配置了，如果他说 mysql 进去 50 分钟搞定了，那么我也要问问他 db 机器啥配置了，如果是普通的吊丝 pc server，那么真实性，大家懂得。然后如果你用 xtrabackup 备份要多久，恢复要多久，大家都知道 copy-back 这一步要很久，那么你有没有办法对这一块优化。
本文中面试要问到的十大注意事项与MySQL问题，在风哥MySQL教程【MySQL DBA数据库高级工程师视频专题1.0（终身门徒套餐）】 课程地址：http://edu.51cto.com/sd/1e1a6 ）中全部涉及到了。

六、关于熟悉 mysql 的锁机制
gap 锁， next-key 锁，以及 innodb 的行锁是怎么实现的，以及 myisam 的锁是怎么实现的等
Innodb 的锁的策略为 next-key 锁，即 record lock+gap lock。是通过在 index 上加 lock 实现的，如果 index 为 unique index，则降级为 record lock,如果是普通 index，则为 next-key lock，如果没有 index，则直接锁住全表。 myisam 直接使用全表扫描。

七、对于简历中写有批量 MySQL 数据库服务器的管理经验
这个如果他说有的话，我会先问他们现在实际线上的 mysql 数据库数量有多少，分多少个节点组，最后问这些节点组上面的 slow log 是如何组合在一起来统计分析的。如果这些他都答对了，那么我还有一问，就是现在手上有 600 台数据库，新来的机器， Mysql 都
安装好了，那么你如 何在最快的时间里面把这 600 台 mysql 数据库的 mysqld 服务启动起来。这个重点在于最快的时间，而能准确回答出清晰思路的只有 2 个人。
slow log 分析：可以通过一个管理服务器定时去各台 MySQL 服务器上面 mv 并且 cp slowlog，
然后分析入库，页面展示。最快的时间里面启动 600 台服务器： 肯定是多线程。 可以用 pssh， ansible 等多线程批量管理服务器的工具
八、对于有丰富的 SQL 优化的经验
首先问 mysql 中 sql 优化的思路，如果能准备说出来， ok，那么我就开始问 explain的各种参数了，重点是 select_type， type， possible_key, ref,rows,extra 等参数的各种
值的含义，如果他都回答正确了，那么我再问 file sort 的含义以及什么时候会出现这个分析结果，如果这里他也回答对了，那么我就准备问 profile 分析了，如果这里他也答对了，那么我就会再问一个问 题，
一个 6 亿的表 a，一个 3 亿的表 b，通过外间 tid 关联，你如何最快的查询出满足条件的第 50000 到第 50200中的这 200 条数据记录。
Explain 在上面的题目中有了，这里就不说了。如何最快的查询出满足条件的第 50000 到第 50200 中的这 200 条数据记录？
limit 10000,20的意思扫描满足条件的10020行,扔掉前面的10000行,返回最后的20行。
九、对于有丰富的数据库设计经验
 mysql 中varchar(60) 60 是啥含义， int(30)中 30 是啥含义？ 如果他都回答对了，那么我就问 mysql中为什么要这么设计呢？
如果他还回答对了，我就继续问 int(20)存储的数字的上限和下限是多少？这个问题难道了全部的 mysql dba 的应聘者，不得不佩服提出这个问题的金总的睿智啊，因为这个问题回答正确了，
那么他确实认认真真地研究了 mysql 的设计中关于字段类型的细节。至 于丰富的设计数据库的经验，不用着急，这不我上面还有更加厉害的 dba吗，他会搞明白的，那就跟我无关了。
varchar(60)的 60 表示最多可以存储 60 个字符。int(30)的 30 表示客户端显示这个字段的宽度。
为何这么设计？说不清楚，请大家补充 。 int(20)的上限为 2147483647(signed)或者4294967295(unsigned)。

十、关于 mysql 参数优化的经验
首先问他它们线上 mysql 数据库是怎么安装的，如果说是 rpm 安装的，那么我就直接问调优参数了，如果是源码安装的，那么我就要问编译中的一些参数了，比如 my.cnf 以及存储引擎以及字符类型等等。 这些内容在风哥MySQL学习教程中的第7阶段讲了很多，然后从以下几个方面问起：
（ 1） mysql 有哪些 global 内存参数，有哪些 local 内存参数。
Global:
innodb_buffer_pool_size

innodb_additional_mem_pool_size

innodb_log_buffer_size

key_buffer_size

query_cache_size

table_open_cache

table_definition_cache

thread_cache_size
Local:
read_buffer_size

read_rnd_buffer_size

sort_buffer_size

join_buffer_size

binlog_cache_size

tmp_table_size

thread_stack

bulk_insert_buffer_size
（ 2） mysql 的写入参数需要调整哪些？重要的几个写参数的几个值得含义以及适用场景，
比如 innodb_flush_log_at_trx_commit 等。 (求补充)
sync_binlog 设置为 1，保证 binlog 的安全性。
innodb_flush_log_at_trx_commit：0：事务提交时不将 redo log buffer 写入磁盘(仅每秒进行 master thread 刷新，安全
性最差，性能最好)1：事务提交时将 redo log buffer 写入磁盘(安全性最好，性能最差， 推荐生产使用)2：事务提交时仅将 redo log buffer 写入操作系统缓存(安全性和性能都居中，当 mysql宕机但是操作系统不宕机则不丢数据，如果操作系统宕机，最多丢一秒数据)
innodb_io_capacity/innodb_io_capacity_max：看磁盘的性能来定。如果是 HDD 可以设置为 200-几百不等。如果是 SSD，推荐为 4000 左右。 innodb_io_capacity_max 更大一些。
innodb_flush_method 设置为 O_DIRECT。

（ 3） 读取的话，那几个全局的 pool 的值的设置，以及几个 local 的 buffer 的设置。
Global:
innodb_buffer_pool_size:设置为可用内存的 50%-60%左右，如果不够，再慢慢上调。
innodb_additional_mem_pool_size：采用默认值 8M 即可。
innodb_log_buffer_size:默认值 8M 即可。
key_buffer_size:myisam 表需要的 buffer size，选择基本都用 innodb，所以采用默认的 8M 即可。
Local:
join_buffer_size： 当 sql 有 BNL 和 BKA 的时候，需要用的 buffer_size(plain index
scans, range index scans 的时候可能也会用到)。默认为 256k，建议设置为 16M-32M。
read_rnd_buffer_size：当使用 mrr 时，用到的 buffer。默认为 256k，建议设置为16-32M。
read_buffer_size:当顺序扫描一个 myisam 表，需要用到这个 buffer。或者用来决定memory table 的大小。或者所有的 engine 类型做如下操作：order by 的时候用 temporaryfile、 SELECT INTO … OUTFILE 'filename' 、 For caching results of nested queries。默认为 128K，建议为 16M。
sort_buffer_size： sql 语句用来进行 sort 操作(order by,group by)的 buffer。如果 buffer 不够，则需要建立 temporary file。如果在 show global status 中发现有大量的 Sort_merge_passes 值，则需要考虑调大 sort_buffer_size。默认为 256k，建议设置为 16-32M。
binlog_cache_size： 表示每个 session 中存放 transaction 的 binlog 的 cache size。默认 32K。一般使用默认值即可。如果有大事务，可以考虑调大。
thread_stack： 每个进程都需要有，默认为 256K，使用默认值即可。
（ 4） 还有就是著名的 query cache 了，以及 query cache 的适用场景了，这里有一个陷阱，
就是高并发的情况下，比如双十一的时候， query cache 开还是不开，开了怎么保证高并发，不开又有何别的考虑？建议关闭，上了性能反而更差。