oldguo(郭老师)
1. 回顾（知识点+故障案例+项目）
1.1 知识点
第一章节 数据库的介绍
（1） 产品分类
	RDBMS   ： MySQL、Oracle（11G,12C）、PG、MSSQL
			   DB-ENGINES.com
	建议：除了MySQL，额外多掌握一款其他的数据库
		  1. 安装   
		  2.体系结构   
		  3. 基础管理 (用户，权限，网络，表空间，数据文件)  
		  4. 备份恢复（expdb/impdp , rman）
		  5. 高可用 (RAC \ DG)
	NoSQL   ： Redis 、MongoDB、ES  
	NewSQL  ： TiDB 
	云数据库： RDS + PolarDB

（2）MySQL数据库的分支和版本
    MySQL : 
			Oracle MySQL : 5.6 / 5.7 / 8.0  
			Percona MySQL 
			MariaDB 
			RDS/TDB
	Oracle :
		   11g : 11.2.0.4 
		   12c : 12.2.x
		   18c : 

第二章节 MySQL的安装
（1） 安装方式
Linux：
	  二进制安装
	  源码安装
	  yum安装
windows、MAC： 
	  下载安装一下

第三章节 MySQL体系结构及基础管理
（1） C/S工作模型
（2） 实例（服务进程+线程+预分配内存）
（3） MySQL程序结构(mysqld构成)
	  Server层： 连接层+SQL层
	  engine层:  插件式的存储引擎
	  SQL基本的执行流程。
（4） MySQL逻辑结构
	  库: 库名+库属性
	  表：表名+列+数据行+表属性
（5） MySQL的物理结构
	  段 ： 1个表就是一个段(分区表除外)。
	  区 ： 连续的64个page，1M。 
	  页 ： 16KB，连续的4个OS block。
	  
（6） 用户、权限管理
	  先建立用户，后授权。
	  
（7） 连接管理
	mysql
	sqlyog
	navicat
	workbench  : 自己扩展 windows版本
	API 
（8） MySQL的启动关闭
	自带启动脚本： support-files/mysql.server  ---> sys-v ---> systemd
    mysqld  &
	mysqld_safe &
	例子： 
		mysqld_safe --defaults-file=/opt/my.cnf &
		mysqld_safe --skip-grant-tables --skip-networking &
	mysqladmin 
（9）配置文件使用
	默认读取路径
	格式：
		[标签] ： 服务器端，客户端
		 配置

（10）多实例配置

第四章节 SQL （运维笔试）
（1） SQL_MODE 
Only_full_group_by
5.7 版本新加入的，select后的列，如果没有在group by 或者没有在函数中。
（2） 字符集  utf8  utf8mb4   ---> emoji
（3） 数据类型 ： char 和 varchar
（4） DDL规范，ONLINE DDL---> pt-osc ，gh-ost *****
（5） delete truncate drop table 不同点
（6） select ： 
单表：
select 
 ---> from 
 ---> where  
 ---> group  by 
 ---> select_list
 ---> having 
 ---> order by
 ---> limit
多表： 
a join b  
on a.xxx=b.yyy
where 
group by ....
left join : 强制驱动表。
（7） information_schema.tables  \ columns

第五章节 索引及执行计划管理
（1）MySQL的索引类型
	 Btree 
	 RTREE
	 HASH
	 FULLTEXT
	 GIS
（2）MySQL Btree索引的构建逻辑 *****
	 聚簇索引   select * from t1 where id=10
	 辅助索引   select * from t1 where name='zs';
	 
	 回表？
	 辅助索引--ID--->聚簇索引。
	 
	 带来问题？
	 带来大量的随机IO。
	 
	 减少回表？
		联合索引？
		MRR？
	  
（3）MySQL 索引树高度影响因素？
	 
（4）执行计划
explain/desc   sql 
type    : 表现的是否用了索引，索引的级别。
key_len ：联合索引应用是否合理。
extra   ：filesort


处理方法： 
1. SQL （脱敏） 
2. 执行计划 （select）
3. show processlist;
4. 锁信息。（I_S,P_S,SYS）

注意态度.

第六章节  存储引擎
（1） 种类 
	InnoDB 
	MyISAM
	Memory
	CSV
	Blackhole
	..
	ToukuDB
	Myrocks 

了解下区别。

（2） 操作
	alter table t1 engine=innodb;
	optimize table t1;
	
	碎片？
	HWM？---> 高水位线
	全表扫描和>范围查询 
	alter table t1 discard tablespace;
	alter table t1 import tablespace;
	
(3) InnoDB核心特性
- MVCC（多版本并发控制）
- 聚簇索引（PK） *****
- 事务     *****  
- 最小锁单元是行级锁 *****
- 外键（FK）
- 复制支持高级特性：GTID等高级复制
- 自适应hash索引
- 支持热备份，不需要锁表就可以热备份
- ACSR（自动故障恢复）

- change buffer（Insert buffer）？ 
- double write 二次写  ，防止出现磁盘数据页出现pw问题。
- AHI 自适应hash索引，将频繁访问索引页，建立内存HASH表，达到快速访问这些索引的目的。

（4） 事务
	ACID  *****
	MVCC  *****
	锁    *****
	隔离级别 *****

第七章节 日志管理
1. 错误日志
2. 二进制日志
	(1)如何查看
	(2)如何截取
		position
		gtid 要注意什么？
		--skip-gtids
	binlog2sql?
	使用场景：binlog2sql是根据mysql的binlog （要求格式是row）
	反解析出delete，update操作，对误操作数据进行还原。	
	
	binlog_format ---> insert update  delete 
		SBR
		RBR
		MBR
	
3. 慢日志
   开启
   模拟慢语句
   分析处理（mysqldumpslow,pt-query-digest）
   抓到慢语句，处理思路--》select
	DDL --> 应急 ---> show processlist ---> MDL  ---> kill id 
	说明： kill 操作无法快速kill，怎么办？
		   pt-kill 工具 
		   processid----> SQL id ----> OS id ---> os  kill  
	
第八章节备份恢复
1. 职责
（1）设计备份策略
	 备份工具：
	 100G以内: 逻辑备份  / 物理备份
	 100G以上-TB：物理备份 
	 超大数据： 
			有条件，有钱： 物理备份较快
			考虑到存储方面： 分布式架构+逻辑备份+压缩
	备份周期：
		数据量小，可以每天全备+binlog
		数据量大，可以每周或每月全备+增量+binlog
（2）备份检查。
	 成功与否： 日志，备份大小，备份集情况。
（3）备份恢复演练
（4）数据快速恢复。
	 常规： 全备+增量+binlog 
	 灵活： 
		  物理损坏： 
				主从或者高可用
		  逻辑损坏： 
				删库        
					10个库，1T，误删除库100M。
				删表
					1000张表，1T，误删除100M表
				方案：
				（1）从全备中提取 单库 单表 的数据进行恢复
			    （2）延时从
				数据行误操作
				binlog2sql
				
 (5) 数据库的迁移升级
	 5.7  升级到  8.0  ,无法回退。 
  		
 2. 备份工具使用 
	mysqldump   （mdp）
	--master-data=2
	--single-transaction
	--max-allowed-packet=64M
	
	mysqldump 全库备份过程中怎么加锁的？加了什么锁？
	对于非innodb表（FTWRL）,对于mysql库下系统表备份的时候，会加global read lock
	
	xtrabackup  （xbk）
	
	mydumper    （自己扩展）
	into outfile  / load data infile(自己扩展)

第九章 主库复制
1. 主从复制的前提（搭建过程）
(1) 两台以上数据库实例,需要不同的server_id ,server_uuid保持不同
(2) 主库需要开启二进制日志(binlog),专用复制用户
(3) 进行主库数据,恢复到从库.
(4) 从库:change master to , 通知从库,
主库:user,password (专用的),ip,port,复制的起点.
(5) 从库:start slave; 开启专用的复制线程

2. 主从复制原理
略。


3. 主从复制的监控

show slave status \G  


4. 主从复制故障 
SQL 
IO

5. 主从延时
主库原因
从库原因

6. 特殊的从库
延时
过滤
半同步？
1. 从库IO线程，将接收到的binlog写入relay-log中后，返回ACK确认
2. 主库ACK_rec线程，接收到ACK确认之后，主库库事务才commit成功
3. 如果主库10秒(默认值)，还没有接收到ACK确认。此次复制会被切换为异步复制。	

MGR，研究一下工作原理。
paxos协议？

传统复制 ：
吃饭？    包子 + 鸡蛋 + 粥
oldxu     主库 
oldguo    从库 
oldqiang  从库


7. MGR
Paxos：
投票决定吃什么
1. 微信群
情景一：
2. leader 发起者  ， follower 跟随者
oldxu  : 今天吃啥？我提议吃包子,咋样？1票
oldguo : +1，附议 。1+1=2票。
oldqiang: +1,1+1=2票。
情景二：
oldxu  : 今天吃啥？我提议吃火锅,咋样？1票
oldguo : +1，附议 。1+1=2票。
oldqiang: 今天不舒服，能不能喝粥？喝粥：+1
情景三：
oldxu  :  今天吃啥？我提议吃火锅,咋样？1票
oldguo :  能不能吃包子？ 包+1
oldqiang: 今天不舒服，能不能喝粥？喝粥：+1

oldxu  :  今天吃啥？我提议吃火锅,咋样？1票
oldqiang: 今天不舒服，能不能喝粥？喝粥：+1 leader
oldguo :  喝粥+1
oldxu  :  那好吧，那我们去喝粥吧。


8. GTID复制
	binlog截取，基于GTID方式。
	主库传输日志，将串行转换为并行
	从库SQL线程，回放日志可以并行。


第十章节 MHA高可用架构
1. 设计高可用架构
2. MHA故障切换的原理
3. MHA故障处理
4. 配合读写分离： ProxySQL / Atlas / Maxscale / Mycat /DBLE

其他的高可用方案：
PXC 
MGC
InnoDB Cluster

第十一章节 分布式架构-Mycat/DBLE/sharding-jdbc
Mycat+MHA 设计与实现

第十二章节 MySQL优化 

1. 优化思路： 
	硬件层面 
	--> OS 
	---> FS 
	---> Mysql实例 
	---> 逻辑结构 
	--->SQL,索引,锁--->架构	

2. 实例： 参数   variables ---> status 
3. 逻辑结构： schema设计： 库，表设计规范，DDL操作
4. 语句优化
索引优化： 优化查询
锁排查  ： 
SQL语句改写

5. 架构： 高可用，高性能


优化工具：
	系统 ： top iostat...
	MySQL:  
	show processlist  
	slowlog  
	explain 
    IS,PS,SYS
	show engine innodb status  
	show status 
	show variables 
	mysqldumpslow / pt 
	pt-toolkits 加强一下
	
1.2 故障案例
数据库的故障类

1. 故障类:
你在日常工作中遇到过什么故障?
你在日常工作中处理过什么故障?
你平常工作都干什么活?


故障列表：
(1) 软件版本,64位 ,32位选择错误.
 
(2) 安装故障:
	1. 用户没创建,权限没给
	2. mysqld,mysql_install_db 
	   本地mariadb没卸载,/etc/my.cnf
	   初始化时会失败.
	3. 配置文件实际情况不对应(basedir,datadir)
	4. 重启,数据盘没有自动挂载(/dev/sdb  ====> /data).
	Linux 多路径 multipath
	
	
排查思路:看日志.	
此处,可以加入个人情感.


5. 升级导致链接失败. 5.5 --> 8.0
	   领导让测试8.0的环境.我下载了8.0.1x.安装到了测试服务器.
	   原生产核心功能表的一部分数据MDP工具导出来,恢复到测试中.
	   进行应用测试,发现连接不上.通过查看官方文档8.0(what is new?)
	   8.0 密码和用户管理发生了巨大变化.先升级到5.7 在升级到8.0 
	   sql_mode,数据类型差别



(3) 数据库连接不上
	1. 网络不通(网线,网卡,bond,交换,路由,回路,网络流量满负荷)
	   防火墙 ,-F 
	   写错规则, 内网服务器不能访问.
	   规则冲突
	2. 没启动,端口,IP
	3. 应用端客户端工具版本过低
	https://downloads.mysql.com/archives/
	
	4. 连接数
	214问题？ 
	limits.conf 
	还没生效
	重启mysql
	配置修改为1000,但是最终生效的是214个Connections? 为啥? 
	/etc/curity/limits.conf  
	nofile    文件句柄数放开限制 65535 
	http 409错误,达到连接数上限

	redis雪崩,穿透
	redis kv 设置了过期时间,大批量失效.
	集群节点丢失.
	   
日志
show processlist;
show status like max_used_connections	       
		   
		   	   
(4)	 配置文件问题

(5)  多实例
OOM  out  of  Memory



(6)  sql_mode (group by,时间类型):迁移升级
(7)  数据类型 
(8)  字符集:乱码
(9)  校对规则问题  
(10) update问题 , binlog2sql
binlog_format=row
binlog 反转

(11) DDL,数据库hang主. show processlist; pt-osc

(12) select查询语句慢.头一天好好的,第二天就慢. 
optimize table t1;
analyze table t1;

(13)
慢语句处理,同一个存储过程一天内执行了几十次.
slowlog,抓到是一个存储过程,执行几十次.

(15) delete , binlog2sql 翻转 , delete 替换为 update 

(16) 索引问题:
	冗余索引过多,索引列比较长(前缀),联合索引(索引覆盖长度,顺序)
	slowlog----->explain---->索引 
	
(17) 存储引擎
	 1. 表空间迁移
	 2. 每周六全备,其他时候binlog增量.
		异常断电,binlog损坏,ibdata1损坏
		
     3. 碎片整理		
		alter table t1 engine innodb;
	 4. 锁等待	
	 5. 幻读,不可重复读

(18) 日志
	1. reset master,rm -fr ,导致主从IO线程故障.
	数据库如果出现损坏,无法完整恢复
	2. gtid : --skip-gtids,导致数据无法恢复.
	3. slowlog
	
(19) 备份恢复 
	 1. mysqldump 加了 --set-gtid-purged=off,主从构建不成功
	 2. --max_allowed_packet,大表备份时报错
	 3. -E -R --triggers没加
	 4. xbk增量合并失败.

(20) 主从
	 1. 主从故障: IO ,SQL  show slave status\G
	 2. 主从延时: 延时时间,日志量差异
	 3. 主从不一致: 从库宕机.pt工具.(pt-sync,pt-checksum)
	 4.延时从库,解决逻辑故障.	
	 5. 过滤复制,只复制了部分库.没有复制mysql,查询时连接不上或者没有权限
     6. gtid复制搭建

(21) 高可用MHA ,只有vip功能,缺了binlogserver ,故障提醒功能	
	1.  MHA+keepalive,权重问题	 

(22) 分布式Mycat 
	1.  分片方式,策略设计不合理
	2.  跨分片join   全局表   ER表
	
(23) 优化 
	1. innodb_flush_log_at_trx_commit=0
	2. sync_binlog=0
	3. innodb_flush_method=fsync 占用大量的额外内存,
	配合固态盘使用O_direct

1.3 项目
 数据库的故障及简历项目梳理(部分)

1、故障类

1.1 利用表空间迁移恢复数据（真实学生案例）
项目背景：服务器断电重启后，MySQL无法启动，没有备份、没有二进制日志，有个一年前的备份
项目需求：让MySQL启动起来，恢复生产业务
项目方案：
    1.首先对现存数据进行备份，防止方案出错导致数据丢失
    2.将一年前备份中的表结构备份出来导入到测试库
    3.将所有表空间删除，为了确保成功执行，跳过外键检查
    4.利用表空间迁移技术，实现数据在无备份时的恢复
    5.将数据库中所有表的ibd文件拷贝到准备好的环境中，恢复生产 

1.2 平常处理过的MySQL问题--碎片处理（真实案例）
1.2.1 环境:
centos7.4,MySQL 5.7.20,InnoDB存储引擎
1.2.2 业务特点:
数据量级较大,经常需要按月删除历史数据.
1.2.3 问题:
磁盘空间占用很大,不释放
1.2.4 处理方法:
以前:将数据逻辑导出,手工drop表,然后导入进去
现在:
对表进行按月进行分表(partition,中间件)
业务替换为truncate方式

alter table t1 engine=innodb; 
optimize table t1;


1.3 企业故障恢复案例
1.3.1 背景环境：
正在运行的网站系统，mysql-5.7.20 数据库，数据量50G，日业务增量1-5M。
1.3.2 备份策略：
每天23:00点，计划任务调用mysqldump执行全备脚本
1.3.3 故障时间点：
年底故障演练:模拟周三上午10点误删除数据库，并进行恢复.
1.3.4 思路：
1、停业务，避免数据的二次伤害
2、找一个临时库，恢复周三23：00全备
3、截取周二23：00  --- 周三10点误删除之间的binlog，恢复到临时库
4、测试可用性和完整性
5、 
    5.1 方法一：直接使用临时库顶替原生产库，前端应用割接到新库
    5.2 方法二：将误删除的表导出，导入到原生产库
6、开启业务
处理结果：经过20分钟的处理，最终业务恢复正常	



1.4 Redis生产故障处理
1.4.1 问题描述：
公司活动优惠券过期仍可使用
1.4.2排查过程：
1.	Redis查看优惠券对应的key发现TTL值发生变化
2.	联系开发查看是否对优惠券对应的key进行重新赋值，覆盖掉了原来的值。 
3.	经开发确认确实由于后期对key进行了覆盖，导致原来的TTL无效
1.4.3解决方案：
1.	要求开发将关键值进行提交
2.	添加自定义监控项，一旦发现提交的key的TTL值发生了异常就报警



1.5 Redis集群内存故障处理
1.5.1 故障描述：
redis-cluster某个分片内存飙升，明显比其他分片高，而且还在增长，并且主从内存使用不一致
1.5.2 排查过程：
1.	排查时主从复制无故障，较大的键值也不存在
2.	查看redis的info信息，发现client_longest_output_list数据异常
3.	分析原因应该是输出缓冲区占用内存较大，也就是有大量的数据从Redis服务器向某些
1.5.3 客户端输出
4.	使用client list命令redis-cli -h host -p port client list | grep -v "omem=0"，来查询输出缓冲区不为0的客户端连接，查询到monitor
1.5.4 处理办法：
1.	进行主从切换，继续观察新的master是否有异常，通过观察未出现异常
2.	查找到真正的原因是monitor，关闭掉monitor的后，内存很快就降下来了
3.	将monitor命令进行重命名，避免再次错误操作启动monitor进程
4.	增加监控项，一旦发现monitor异常运行及时关闭


2、架构
2.1 架构改造项目
2.1.1项目背景:
2台  IBM X3650   32G  ,原来主从关系,2年多没有主从了,"小问题"不断(锁,宕机后的安全)
MySQL 5.1.77   默认存储引擎 MyISAM  
数据量: 60G左右 ,每周全备,没有开二进制日志
2.1.2 架构方案:
    1. 升级数据库版本到5.7.20 
    2. 更新所有业务表的存储引擎为InnoDB
    3. 重新设计备份策略为热备份,每天全备,并备份日志
    4. 重新构建主从
2.1.3结果:
    1.性能
    2.安全方面
    3.快速故障处理
								
2.2 Mysql数据库架构升级（MHA+Mycat，真实学生案例9T数据）
2.2.1 项目背景：
原数据库架构为mysql一主两从结构，存在单点故障，一旦出现故障，恢复操作复杂且耗费时间较长
2.2.2 实施过程：
1.	评估当前业务需求，定架构为MHA（高可用）+Mycat（读写分离+分布式）
2.	涉及并实施MHA+MyCAT高可用分布式架构 
3.	利用XBK方式将数据库迁移到MHA+MyCAT架构
2.2.3 项目效果：
1.解决了数据库单点故障，并且大大降低了MySQL故障恢复的时间，可以在10-15s内完成故障恢复
2.实现了分布式读写需求，大大提高了业务读写性能


2.3 zabbix监控系统升级（真实学生案例）
2.3.1 问题描述：
zabbix查询缓慢，每隔三四个月需要重新搭建，存储空间经常被占满
2.3.2 排查过程：
1.	硬件设备正常，无问题。
2.	查看zabbix版本，数据库版本，以及存储引擎，发现zabbix版本为3.2，数据库mariaDB 5.5，存储引擎为InnoDB。
2.3.3 解决方案：
1.	升级zabbix版本为4.0
2.	更改数据库为Mariadb，存储引擎修改为tokudb，因为tokudb比InnoDB效率高，且压缩比更高。

3、 优化类
3.1 优化大型监控系统（监控千台以上，学生案例）
3.1.1 环境: 
zabbix 3.2    mariaDB 5.5  centos 7.3
3.1.2 现象 : 
zabbix卡的要死 ,  每隔3-4个月,都要重新搭建一遍zabbix,存储空间经常爆满.
3.1.3 分析问题 :
1. zabbix 版本 
2. 数据库版本
3. zabbix数据库500G,存在一个文件里
3.1.4 优化建议:
1.数据库版本升级到5.7版本,zabbix升级更高版本
2.存储引擎改为tokudb
3.监控数据按月份进行切割(二次开发:zabbix 数据保留机制功能重写,数据库分表)
4.关闭binlog和双1
5.参数调整....
3.1.5 优化结果:
监控状态良好


3.1.6 为什么?（不需要体现在简历中，面试官问再说）
1. 原生态支持TokuDB,另外经过测试环境,5.7要比5.5 版本性能 高  2-3倍
2. TokuDB:insert数据比Innodb快的多，数据压缩比要Innodb高
3.监控数据按月份进行切割,为了能够truncate每个分区表,立即释放空间
4.关闭binlog ----->减少无关日志的记录.
5.参数调整...----->安全性参数关闭,提高性能.



3.2 存储引擎优化（真实案例）
3.2.1 环境: 
centos 5.8 ,MySQL 5.0版本,MyISAM存储引擎,网站业务(LNMP),数据量50G左右
现象问题: 业务压力大的时候,非常卡;经历过宕机,会有部分数据丢失.
3.2.2 问题分析:
1.MyISAM存储引擎表级锁,在高并发时,会有很高锁等待
2.MyISAM存储引擎不支持事务,在断电时,会有可能丢失数据
3.2.3 职责
1.监控锁的情况:有很多的表锁等待
2.存储引擎查看:所有表默认是MyISAM
3.2.4 解决方案:
1.升级MySQL 5.6.10版本
2. 迁移所有表到新环境
3. 开启双1安全参数


3.3 SQL语句优化（真实学生案例）
3.3.1 项目背景：
zabbix监控到web页面响应缓慢，公司业务慢，MySQL出现性能问题：
    1.应急性的慢，突然夯住
    2.一段时间慢，持续性
3.3.2 项目需求：
优化MySQL性能及SQL语句，提升用户服务体验
3.3.3 项目方案：
    1.show processlist;记录慢日志slowlog，获取导致数据库夯住并缓慢的SQL语句
    2.在测试库中，从锁等待、索引等方面分析SQL语句执行计划
    3.对SQL语句进行调优，有锁等待的调整顺序，索引走的不正确的修改语句，没有索引的创建索引
    4.在测试库中进行测试，总结效果，交给开发进行测试
    5.对在测试库中执行没有问题的SQL语句，结合zabbix监控记录及对硬件CPU进行分析，硬件是否达到瓶颈需要升级

	
3.4 锁优化项目
3.4.1. 背景: 
硬件环境: DELL R720,E系列16核,48G MEM,SAS*900G*6,RAID10
在例行巡检时,发现9-11点时间段的CPU压力非常高(80-90%)

3.4.2. 项目的职责
    2.1 通过top详细排查,发现mysqld进程占比达到了700-800%
    2.2 其中有量的CPU是被用作的SYS和WAIT,us处于正常
    2.3 怀疑是MySQL 锁 或者SQL语句出了问题
    2.4 经过排查slowlog及锁等待情况,发现有大量锁等待及少量慢语句    
    (1) pt-query-diagest 查看慢日志  
    (2) 锁等待有没有?
    db03 [(none)]>show status like 'innodb_row_lock%';
    +-------------------------------+-------+
    | Variable_name                 | Value |
    +-------------------------------+-------+
    | Innodb_row_lock_current_waits | 0     |
    | Innodb_row_lock_time          | 0     |
    | Innodb_row_lock_time_avg      | 0     |
    | Innodb_row_lock_time_max      | 0     |
    | Innodb_row_lock_waits         | 0     |
    +-------------------------------+-------+
    情况一:
            有100多个current_waits,说明当前很多锁等待情况
    情况二:
            1000多个lock_waits,说明历史上发生过的锁等待很多
    2.5 查看那个事务在等待(被阻塞了)
    2.6 查看锁源事务信息(谁锁的我)
    2.7 找到锁源的thread_id 
    2.8 找到锁源的SQL语句
3.4.3. 找到语句之后,和应用开发人员进行协商   
    (1)
    开发人员描述,此语句是事务挂起导致
    我们提出建议是临时kill 会话,最终解决问题
    (2) 
    开发人员查看后,发现是业务逻辑问题导致的死锁,产生了大量锁等待
    临时解决方案,将阻塞事务的会话kill掉.
    最终解决方案,修改代码中的业务逻辑
3.4.4 项目结果:
    经过排查处理,锁等待的个数减少80%.解决了CPU持续峰值的问题.
    
3.4.5 锁监控设计到的命令:（不需要体现在简历，面试官问进行说明即可）
show status like 'innodb_rows_lock%'
select * from information_schema.innodb_trx;
select * from sys.innodb_lock_waits;
select * from performance_schema.threads;
select * from performance_schema.events_statements_current;
select * from performance_schema.events_statements_history;



异构平台迁移案例

项目: 某银行流水信息,大数据处理平台数据迁移
	1. 背景: 
		原环境:  关系型数据库MySQL 5.6.20,数据量30亿条数据,6T.
		新环境:  非关系型数据库:MongoDB 3.2.10
	2. 负责:
	    (1)源库数据导出为部分数据CSV ,做格式处理
		(2)进行初期测试迁移,应用初期测试
		(3)将数据分批导出为CSV,格式处理
		(4)分批导入到MongoDB sharding Cluster 
		(5)正式测试无误
		(6)大数据平台正式运行		
大数据处理平台,爬虫爬来的信息.原来在MySQL,现在迁移到MongoDB   


2. 数据库面试过程问题（技术篇）
（1） 你们公司用了什么数据库产品？
（2） 介绍一下，你熟悉的数据库产品？
（3） 你们公司数据库，数据量多大，什么业务，？
      互联网，电商，教育，贷款，传统行业
（4） 你遇到过什么故障？处理过什么故障？你平常都干啥?
（5） SQL语句的执行过程？
（6） 介绍一下MySQL 物理存储结构？
（7） 你对SQL语句熟练嘛？
	  上家公司，在SQL方面的职责：审核，配合Schema设计，优化。
（8） 你对存储过程熟练吗？
（9） Btree原理？
（10）做过哪些索引方面的优化？
（11）explain的都有哪些指标？
（12）一条SQL前一天好好的，第二天就非常慢？
（13）联合索引原则？最左原则是什么？
（14）ACID？
（15）锁？
（16）事务工作流程？
（17）隔离级别，MVCC？
（18）InnoDB核心特性？
（19）binlog_format?
（20）你们用什么工具备份，备份策略是什么？
（21）mysqldump核心参数，xbk核心参数，备份原理？
（22）简述主从复制的搭建过程，主从复制原理？
（23）主从复制故障，主从延时原因？
（24）异步复制 半同步复制 MGR Paxos
（25）MHA Failover原理
（26）公司架构，例如：mycat
（27）MySQL 怎么优化的？

3. 简历的书写
1. 简历的格式
1.0 创客贴

1.1 个人简介
	姓名,联系方式,学历
1.2(可选): 211 , 985 , 证书, 专业8级

1.3  Linux云计算运维技能列表:
(1)  精通 各类主机,存储,网络设备的配置和管理.
(2)  精通 Centos6/7/8,Ubuntu 14/15/16等各版本操作系统特性.
(3)  精通 Bash Shell 脚本编程,熟练使用AWK,SED,GREP 文本处理命令.
(4)  精通 Linux 存储管理: Raid配置,LVM,XFS文件系统管理等.
(5)  精通 Linux安全管理: 用户权限,SSH秘钥,登录日志,iptables等.
(6)  精通 Linux软件包管理: 源码包,RPM,Yum等软件包管理模式.
(7)  精通 TCP/IP,OSI七层模型,HTTP,ICMP,SNMP各类网络协议工作原理.
(8)  精通 Linux操作系统优化: 系统内核参数,系统限制优化.
(9)  精通 互联网业务系统,全网备份策略的设计与实现.
(10) 精通 主流存储系统: GlusterFS,Ceph,FC-SAN,IP-SAN,NAS.
(11) 精通 Ansiable Playbook,Role应用,实现业务架构批量配置管理.
(12) 精通 LNMT,LNMG,LAMP,LNMP主流互联网业务架构的设计与实施.
(13) 精通 KeepAlive,HAProxy,RoseHA,RHCS主流互联网高可用集群架构设计与实现
(14) 精通 LVS,Nginx,DNS 负载均衡集群设计与实现.
(15) 精通 Zabbix监控系统,实现硬件,系统,应用,网络各项指标全面监控
(16) 精通 gitlab,jenkins,github,gitee代码管理系统,实现代码自动管理.
(17) 精通 ELK,EFK日志分析收集平台.
(18) 精通 KVM,Docker(Registy,Container,Image,NetWork,Dockerfile,Compose),k8s虚拟化,容器云技术.
(19) 精通 MySQL5.6/5.7/8.0版本特性原理
(20) 精通 MySQL mysqldump,Xtrabackup备份策略设计及数据恢复.
(21) 精通 MySQL Replication 主从复制原理及设计实现.
(22) 精通 MySQL MHA,PXC高可用架构的设计,实施,维护.
(23) 精通 Redis Sentinel高可用,Redis Cluster,MongoDB ReplicaSet,MongoDB Sharding Cluster设计与实施.

1.4 DBA技能列表
(1) 熟悉 Oracle MySQL,MariaDB,Percona,Aliyun RDS多类同源MySQL产品特性功能.
(2) 熟悉 MySQL体系结构原理,深入理解MySQL连接层,SQL层,存储引擎层工作原理.
(3) 熟悉 MySQL InnoDB,TokuDB,MyRocks等存储引擎核心特性.
(4) 熟悉 InnoDB事务 ACID、Redo、Undo、MVCC、锁、隔离级别等核心原理实现.
(5) 熟悉 MySQL主从复制原理、主从状态监控、主从故障分析处理、主从延时分析处理
(6) 熟悉 主流MySQL高可用技术MHA,PXC的架构设计与实现.
(7) 熟悉 MDP,XBK工具的备份、恢复流程原理,熟悉不同数据量和业务的备份策略设计与实现.
(8) 熟悉 Redis 安全管理、数据类型、持久化、Replica-set原理
(9) 熟悉 Redis-Sentinel哨兵高可用集群、RedisCluster分布式高可用集群设计与实现.
(10)熟悉 MongoDB复制集原理、MongoDB MSC分片集群工作原理及分片策略定制.
(11)熟悉 Mycat、DBLE企业级分布式架构的设计与实现.
(12)熟悉 MySQL SQL语句应用和规范审核.
(13)熟悉 B+tree构建原理及查找算法,对聚簇索引,辅助索引应用有深入理解.
(14)熟悉 MySQL 优化,对于硬件,OS,文件件系统,数据库实例,SQL,索引,锁,引擎,架构全面优化建议.
(15)熟悉 Linux操作系统,熟练使用Shell编程进行自动化脚本开发.
(16)熟悉 Oracle 基础管理:网络,用户权限,数据文件,表空间,日志,DG,RAC等.
(17)熟悉 Docker Images、Container、Network、Volumes、Dockerfile、Registry、Docker Compose容器管理技术
(18)多年 TB以上级别数据库运维经验,擅长大数据量表的维护及运维工作.

1.5 工作经历(DBA)
2017年6月-至今     xxxx 公司    DBA 运维工程师     
1. 负责数据库实例配置管理、用户安全管理.
2. 配合开发进行schema设计及开发,负责日常SQL审核及优化.
3. 负责MySQL数据库slowlog收集及执行计划分析,进行语句和索引优化.
4. 负责锁、内存等各指标监控及优化.	
5. 日常检查备份可用性检查,定期的恢复演练,版本迁移升级.
6. 主从复制架构的设计、实施、故障监控，延时分析及处理.
7. 负责高可用架构监控,故障处理及主从延迟解决
8. 负责MySQL的分布式高可用架构的设计及实现。
9. 负责设计及优化NoSQL高可用及分布式架构.

2015年9月-2017年6月 xxx 公司      xxxx 工程师