无意中看到阿里巴巴的面试题,,借此回首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