答案是自己理解整理的。。。。。。。。。。。。
1、MySQL的复制原理以及流程
复制有三个步骤：
1、Master将数据改变记录到二进制日志(binary log)中，也就是配置文件log-bin指定的文件，这些记录叫做二进制日志事件(binary log events)
2、Slave通过I/O线程读取Master中的binary log events并写入到它的中继日志(relay log)
3、Slave重做中继日志中的事件，把中继日志中的事件信息一条一条的在本地执行一次，完成数据在本地的存储，从而实现将改变反映到它自己的数据(数据重放)
2、MySQL中myisam与innodb的区别，至少5点
(1)、问5点不同；
1、MyISAM不支持事务，InnoDB是事务类型的存储引擎，当我们的表需要用到事务支持的时候，那肯定是不能选择MyISAM了。
2、MyISAM只支持表级锁，BDB支持页级锁和表级锁默认为页级锁，而InnoDB支持行级锁和表级锁默认为行级锁
3、MyISAM引擎不支持外键，InnoDB支持外键
4、MyISAM引擎的表在大量高并发的读写下会经常出现表损坏的情况
5、对于count()查询来说MyISAM更有优势
6、 InnoDB是为处理巨大数据量时的最大性能设计，它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。
7、MyISAM支持全文索引（FULLTEXT），InnoDB不支持
8、MyISAM引擎的表的查询、更新、插入的效率要比InnoDB高
(2)、innodb引擎的关键特性
一、插入缓冲： 对于非聚集索引的插入和更新，不是每一次直接插入索引页中，而是首先判断插入的非聚集索引页是否在缓冲池中，如果在，则直接插入，否则，先放入一个插入缓冲区中。好似欺骗数据库这个非聚集的索引已经插入到叶子节点了，然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作，这时通常能将多个插入合并到一个操作中，这就大大提高了对非聚集索引执行插入和修改操作的性能。（插入缓冲使用的条件：1、索引是辅助索引； 2、索引不是唯一的；）
二、二次写：主要用于数据恢复。Double write由两部分组成，一部分是内存中的 double write buffer。 另一部分是在物理磁盘上的共享表空间中的连续128个页，大小和内存中（2M）一致。对缓冲池中的页进行刷新时，并不直接写磁盘，而是memcpy到double write buffer. 之后通过 double write buffer 分两次，每次顺序写入共享表空间1M数据，然后马上调用fsync同步磁盘。这个写入因为共享表空间的double write页是连续的，因此开销不是很大。而完成 double write 页的写入后，再将double write buffer中的页写入各个表空间则是离散的写入。
如果操作系统在将页写入磁盘的过程中发生了崩溃。那么恢复时则可以从共享表空间中double write buffer页找到该页的副本。将其复制到表空间再应用重做日志。
三、自适应哈希：
InnoDB存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应（adaptive）的。
自适应哈希索引通过缓冲池的B+树构造而来，因此建立的速度很快。而且不需要将整个表都建哈希索引，InnoDB存储引擎会自动根据访问的频率
限制
1.只能用于等值比较，例如=， <=>，in
2.无法用于排序
3.有冲突可能
4.Mysql自动管理，人为无法干预。
四、异步IO
优势：
1. IO 并行：IO 操作可以并行发出，不必等待前面的IO完成
2. IO Merge操作：将多个IO合并成一个IO，提高IOPS的性能
查询（space,page_no）:(8,6)+(8,7)+(8,8)，每个页16k
原先需要三个IO操作完成，Innodb会判断这三个页是连续的，因此只发送一个查询IO查询48k的页Native AIO只支持Window和Linux，Mac OSX不支持
在Innodb存储引擎中，read ahead方式的读取、脏页的刷新、磁盘的写入都是有AIO方式完成
五、刷新临近页
当刷新一个脏页的时候，Innodb存储引擎会检测该页所在区的所有页，如果都是脏页，使用AIO的IO Merge，一起刷新至磁盘
注意问题：
1. 一个不怎么脏的页，相对与一个被修改多次很脏的页，刷新是否值得。
2. 固态硬盘有着较高的IOPS，建议不开启。（IOPS (Input/Output Operations Per Second)，即每秒进行读写（I/O）操作的次数，多用于数据库等场合，衡量随机访问的性能）
(3)、2者selectcount(*)哪个更快，为什么
myisam更快，因为它已经存了这个count，不用像innodb那样去真正查询行数
3、MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义
(1)、varchar与char的区别
varchar可变长度，char定长
(2)、varchar(50)中50的涵义
最大可存入50个字节。
(3)、int（20）中20的涵义
最大可存入20位数。
是指显示字符的长度 不影响内部存储，只是影响带 zerofill 定义的 int 时，前面补多少个 0，易于报表展示
(4)、mysql为什么这么设计
对大多数应用没有意义，只是规定一些工具用来显示字符的个数；int(1)和int(20)存储和计算均一样；
4、问了innodb的事务与日志的实现方式
(1)、有多少种日志；
重做日志redo和回滚日志undo
(2)、事务的4种隔离级别
未提交读，已提交读，可重复读，序列化读
(3)、事务是如何通过日志来实现的，说得越深入越好。
一般情况下，mysql在崩溃之后，重启服务，innodb通过回滚日志undo将所有已完成并写入磁盘的未完成事务进行rollback，然后redo中的事务全部重新执行一遍即可恢复数据，但是随着redo的量增加，每次从redo的第一条开始恢复就会浪费长的时间，所以引入了checkpoint机制。Checkpoint：如果在某个时间点，脏页的数据被刷新到了磁盘，系统就把这个刷新的时间点记录到redo log的结尾位置，在进行恢复数据的时候，checkpoint时间点之前的数据就不需要进行恢复了，可以缩短时间v
5、问了MySQL binlog的几种日志录入格式以及区别
(1)、binlog的日志格式的种类和分别
1.Statement：每一条会修改数据的sql都会记录在binlog中。 2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。 3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式。也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
(2)、适用场景；
在一条 SQL 操作了多行数据时， statement 更节省空间， row 更占用空间。但是 row模式更可靠。
(3)、结合第一个问题，每一种日志格式在复制中的优劣。
Statement 可能占用空间会相对小一些，传送到 slave 的时间可能也短，但是没有 row模式的可靠。 Row 模式在操作多行数据时更占用空间， 但是可靠。
6、问了下MySQL数据库cpu飙升到500%的话他怎么处理？
当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql， 看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间， 有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等。
7、sql优化
(1)、explain出来的各种item的意义；
(2)、profile的意义以及使用场景；
8、备份计划，mysqldump以及xtranbackup的实现原理
(1)、备份计划；
视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为 mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备份 出来的文件比较小，压缩之后更小)。100G 以上的库，可以考虑用 xtranbackup 来做，备份速度明显要比 mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。
(2)、备份恢复时间；
物理备份恢复快，逻辑备份恢复慢 这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考 20G的2分钟（mysqldump） 80G的30分钟(mysqldump) 111G的30分钟（mysqldump) 288G的3小时（xtra) 3T的4小时（xtra) 逻辑导入时间一般是备份时间的5倍以上
(3)、xtrabackup实现原理
mysqldump
mysqldump 属于逻辑备份。加入--single-transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)， 之后显式开启一个事务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。 如果加上--master-data=1 的话，在刚开始的时候还会加一个数据库的读锁 (FLUSH TABLES WITH READ LOCK),等开启事务后，再记录下数据库此时 binlog 的位置(showmaster status)，马上解锁，再读取表的数据。等所有的数据都已经导完，就可以结束事务
Xtrabackup:
xtrabackup 属于物理备份，直接拷贝表空间文件，同时不断扫描产生的 redo 日志并保存下来。最后完成 innodb 的备份后，会做一个 flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作会丢数据)，确保所有的 redo log 都已经落盘(涉及到事务的两阶段提交 概念，因为 xtrabackup 并不拷贝 binlog，所以必须保证所有的 redo log 都落盘，否则可能会丢最后一组提交事务的数据)。这个时间点就是 innodb 完成备份的时间点，数据文件虽然不是一致性的，但是有这段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事 情)。然后还需要 flush tables with read lock，把 myisam 等其他引擎的表给备份出来，备份完后解锁。 这样就做到了完美的热备。
9、mysqldump中备份出来的sql，如果我想sql文件中，一行只有一个insert....value()的话，怎么办？如果备份需要带上master的复制点信息怎么办？
10、500台db，在最快时间之内重启
可以使用批量 ssh 工具 pssh 来对需要重启的机器执行重启命令。 也可以使用 salt（前提是客户端有安装 salt）或者 ansible（ ansible 只需要 ssh 免登通了就行）等多线程工具同时操作多台服务器
14、你们数据库是否支持emoji表情，如果不支持，如何操作？
mysql数据库的默认字符集utf8，只能存储3个字节的数据。标准的emoji表情是4个字节，在APP端输入保存表情是用户的普遍需求和行为。
解决方式：更换字符集utf8-->utf8mb4 mb4的意思是most bytes 4，专门为兼容四个字节的。utf8mb4是向下兼容utf8的，所以即便修改了字段的字符集也不会影响线上数据。用java查询的时候如果有必要，也要设置下字符集=
17、表中有大字段X(例如：text类型)，且字段X不会经常更新，以读为为主，请问
答：拆带来的问题：连接消耗 + 存储拆分空间；不拆可能带来的问题：查询性能； 如果能容忍拆分带来的空间问题,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序IO,减少连接消耗,最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗 如果能容忍不拆分带来的查询性能损失的话:上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择
18、MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的？为什么是这样子的？
答：InnoDB是基于索引来完成行锁 例: select * from tab_with_index where id = 1 for update; for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列, 如果 id 不是索引键那么InnoDB将完成表锁,,并发将无从谈起