阿里巴巴MySQL DBA面试题答案[转]

无意中看到阿里巴巴的面试题,,借此回首DBMS时刻趁热打铁巩固一下基础

拿到题目大概浏览了一遍难度大概在中上游水平,自己跪了接近35%的题目

自己答题如下,欢迎大家讨论分析题

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228

1、MySQL的复制原理以及流程 . (1)、先问基本原理流程，3个线程以及之间的关联； .     从 发起请求I/O thread线程请求 主     主 接收到请求使用binlog dump线程回应 从     从 I/O thread线程将请求接收下来保存为中继日志     从 再开SQL thread线程将中继线程保存为执行日志 . (2)、再问一致性延时性，数据恢复；( 每个人角度不同 ) .     出发点  是否使用工具   业务线是否正常    备份恢复成本   一致性     热备份       借助        细微影响        偏高       组合才能完全     温备份       借助        受一部分        中等            完全     冷备份        无           停滞         较低            完全 .     mysqldump         innodb热备  结合binlog  启动大事务         innodb温备   最好锁定表(若有事务则需要结合binlog) .     数据恢复:  通常情况下  每周完整  +  周中的增量or差异 + 新的binlog . (3)、再问各种工作遇到的复制bug的解决方法。     手抖将同步时间改太短,导致cpu空转     主主模式主键重复,调整auto_instcrment  . . 2、MySQL中myisam与innodb的区别，至少5点 . (1)、问5点不同； .     事务有无     多版本控制     行锁     热备份     崩溃恢复 . (2)、问各种不同mysql版本的2者的改进； .     同(1)问缺什么补什么     innodb  -> xtradb  性能上的     myisam  -> aria    崩溃恢复 . (3)、2者的索引的实现方式。 .     btree   InnoDB,MyISAM       左节点小于右节点,提高查询效率         rtree   MyISAM             btree是2维结构,,那么rtree多于3维 . . 3、问MySQL中varchar与char的区别以及varchar(50)中的30代表的涵义 . (1)、varchar与char的区别； .     同宽度填不填充0的问题,varchar变长 . (2)、varchar(50)中50的涵义； .     长度50字符 . (3)、int(20)中20的涵义；( 跪了,看了几年了一直没去理解过 - -! ) .     显示宽度 int 4字节 建好字段后为 int(11)  最大表示   -21亿 - +21亿   这是11位哦    int(20)   无意义,这是这么一问 . (4)、为什么MySQL这样设计。(没看明白) . [备注] 本人也面试了近12个2年MySQL DBA经验的朋友，没有一个能回答出第(2)、(3)题 . . . 4、问了innodb的事务与日志的实现方式 . (1)、有多少种日志； .     错误,查询,超时查询,二进制,中继,事务 . (2)、日志的存放形式； .     table,file . (3)、事务是如何通过日志来实现的，说得越深入越好。(总觉得不够!!) . .     流程: 事务发起   ->  内存buffer(提高性能不能一直写磁盘啊)  ->  事务日志  ->  磁盘数据  .     事务日志到磁盘的过程可能会出意外,,再次恢复服务后,,事务日志中事务会自动状态同步到磁盘 . 5、问了MySQL binlog的几种日志录入格式以及区别 . (1)、各种日志格式的涵义； .     statement语句格式   只是语句状态信息   省空间  适应性强   无法精确复制(触发器,函数)     row行格式     能够实现几乎所有的复制场景  较少的cpu占用率  无法准确得知操作  浪费空间     mixed混合格式   怎么方便怎么来  常用 . (2)、适用场景；(自己领悟...) .     屌丝服务器     土豪服务器     文艺服务器 . (3)、结合第一个问题，每一种日志格式在复制中的优劣。 .     语句: 可能会造成数据不一致     行:  日志文件偏大,不易存储转移,恢复也可能比较慢     混合: 理论上结合两者特点 . 6、问了下MySQL数据库cpu飙升到500%的话他怎么处理？ . (1)、没有经验的，可以不问；(如果问到我肯定要选这个啊...) . (2)、有经验的，问他们的处理思路。 .     列出所有进程  show processlist  观察所有进程  多秒没有状态变化的(干掉)     查看超时日志或者错误日志 (做了几年开发,一般会是查询以及大批量的插入会导致cpu与i/o上涨,,,,当然不排除网络状态突然断了,,导致一个请求服务器只接受到一半,,比如where子句或分页子句没有发送,,当然的一次被坑经历) . . 7、sql优化 . (1)、explain出来的各种item的意义；(一谈优化脑海就是sql语句袭来,,索引重建!!!) .     分析当前的select语句,,     select_type  当前查询的类型(简单or连接or组合or子查询)     rows  做笛卡尔积要组合的行     extra  额外信息     (其余的实在没记住) .     考虑将面试官带上其他话题  优化sql中   : )     where  不必要的括号,常量重叠,去除常量条件     范围优化  少用like啊  根据当前的索引选定不同的范围条件啊     多关键字优化  is null, distinct, left/right join, join, union,order by,group by,limit     小表不需要索引:  select * from table force index(index_name) where     索引合并优化   select * from table ignore index(indexname1,indexname2)   一张表有多索引,忽略几个在查,可能提高性能 . (2)、profile的意义以及使用场景；(没看台明白) . (3)、explain中的索引问题。(一问中回答过,,只能说之前的做法是 存储过程+算法)     编译过的sql语句还是相当能提升性能的     还有就是组织一些特有的数据构成  (升序  or  树结构 or ...)     这样在过程中加入一些算法(二分,排序树)进行优化,效果还是比较明显 .     ps: oracle中专门有rank,percent_rank这些函数处理数据         得以于初出茅庐之时为当时国字号企业做的一个'大'数据项目 14W/min         对当时的我来说,天文数字,学到不少东西 . 8、备份计划，mysqldump以及xtranbackup的实现原理 .     mysqldump  做之前要日志滚动,记录同步位置,请求锁     xtranbackup  没有锁表,将二进制,事务日志都备份下来,之后必要要做准备,才能用于还原 . (1)、备份计划； .     前面说过了..当然因业务,实际需求,场景做动态规划 . (2)、备份恢复时间；(没看太明白) .     但是最好在恢复的时候不要进行写操作 . (3)、备份恢复失败如何处理。 .     检查日志排除问题,如果不行删除当前所有数据文件(不包括二进制哦),利用之前完整备份 + 增量 +  二进制再次重试 . 9、500台db，在最快时间之内重启 .     shell脚本, ansible工具 . 10、在当前的工作中，你碰到到的最大的MySQL DB问题是？(对于这个实在没经验) . . 11、innodb的读写参数优化(跪了,,顺手去查询分析的) . (1)、读取参数，global buffer pool以及 local buffer； .     全局缓存池(类似oracle的RAC)     局部缓存器(针对session进行缓存) . (2)、写入参数(不明白)； . (3)、与IO相关的参数； .     innodb_read_io_threads  读io的线程数     innodb_io_capacity      io总量????     innodb_write_io_threads 写io的线程数     innodb_use_native_aio   实现aio就是纯异步 . (4)、缓存参数以及缓存的适用场景。 .     cache大小,cache区块大小,单目标最大,cache区块总大小(单词忘记了  查 query_cache) . 12、请简洁地描述下MySQL中InnoDB支持的四种事务隔离级别名称，以及逐级之间的区别？ .     read uncommitted  可读到未提交数据     read committed    读到提交过后的数据     REPEATABLE-READ   可重读数据     serialization     串行化读完数据 .     (后面送的 :)     更高级的隔离级别     snapshot committer 快照级别一致性提交隔离     snapshot           快照读取 . 13、表中有大字段X(例如：text类型)，且字段X不会经常更新，以读为为主，请问 . (1)、您是选择拆成子表，还是继续放一起； .          拆带来的问题           不拆可能带来的问题     连接消耗 + 存储拆分空间  VS     查询性能 .     如果能容忍拆分带来的空间问题,,,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序IO,减少连接消耗,,,最后这是一个文本列  再加上一个全文索引来尽量抵消连接消耗 .     如果能容忍不拆分带来的查询性能损失的话:     上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择 . (2)、写出您这样选择的理由。 .     已填 (观察过国内外论坛项目的数据库设计,,好像没看见谁拆过,,,感觉想多了,,要不就是我记错了,,,还需要再考证) . 14、MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的？为什么是这样子的？(跪了,google一下) .     (这是我自己不知道答案前YY的,不要当真)程序做这样的处理一般都会用单例模式多次锁定(保 持当前对象的状态值),数据库也类型处理吧!!将当前行状态标记为锁定中..还有那一个线程锁的.. .     google了一下,, InnoDB是基于索引来完成行锁    例: select * from tab_with_index where id = 1 for update;     for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,     如果 id 不是索引键那么InnoDB将完成表锁,,并发将无从谈起 . . .

本文出自 “Apprentice” 博客，请务必保留此出处http://apprentice.blog.51cto.com/2214645/1394494