1、简述btree和hash索引的区别。
- hash索引查找数据基本上能一次定位数据，当然有大量碰撞的话性能也会下降。而btree索引就得在节点上挨着查找了，很明显在数据精确查找方面hash索引的效率是要高于btree的；
- 那么不精确查找呢，也很明显，因为hash算法是基于等值计算的，所以对于“like”等范围查找hash索引无效，不支持；
- 对于btree支持的联合索引的最优前缀，hash也是无法支持的，联合索引中的字段要么全用要么全不用。提起最优前缀居然都泛起迷糊了，看来有时候放空得太厉害；
- hash不支持索引排序，索引值和计算出来的hash值大小并不一定一致。
2、分析explain执行的sql语句每行代表的意思。 mysql> explain select * from user_info where id = 2\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: user_info partitions: NULL type: const possible_keys: PRIMARY key: PRIMARY key_len: 8 ref: const rows: 1 filtered: 100.00 Extra: NULL row in set, 1 warning (0.00 sec)
3、实现基于mysqldump备份数据库，并还原。
mysqldump备份简述 mysqldump可产生两种类型的输出文件，取决于是否选用- -tab=dir_name选项。
l 不使用- -tab=dir_name选项，mysqldump产生的数据文件是纯文本的SQL文件，又CREATE（数据库、表、存储路径等）语句和INSERT（记录）语句组成。输出结果以一个文件保存，可以用mysql命令去恢复备份文件。
l 使用- -tab=dir_name选项，mysqldump对于每一个需备份的数据表产生两个输出文件：一个是带分隔符的文本文件，备份的数据表中的每行存储为文本中的一行，以“表名.txt”保存；另一个输出文件为数据表的CREATE TABLE语句，以“表名.sql”保存。
- -all-databases表示备份系统中所有数据库，使用- -databases参数之后，必须指定至少一个数据库的名称，多个数据库名称之间用空格隔开
【常用的选项】
-
- -add-drop-table
这个选项将会在每一个表的前面加上DROP TABLE IF EXISTS语句，这样可以保证导回MySQL数据库的时候不会出错，因为每次导回的时候，都会首先检查表是否存在，存在就删除
-
- -add-locks
这个选项会在INSERT语句中捆上一个LOCK TABLE和UNLOCK TABLE语句。这就防止在这些记录被再次导入数据库时其他用户对表进行的操作
-
- -tab
这个选项将会创建两个文件，一个是带分隔符的文本文件，备份的数据表中的每行存储为文本中的一行，以“表名.txt”保存；另一个输出文件为数据表的CREATE TABLE语句，以“表名.sql”保存。
-
--quick或者—opt
)如果你未使用--quick或者--opt选项，那么mysqldump将在转储结果之前把全部内容载入到内存中。这在你转储大数据量的数据库时将会有些问题。该选项默认是打开的，但可以使用--skip-opt来关闭它。
-
--skip-comments
使用--skip-comments可以去掉导出文件中的注释语句
-
–compact
使用--compact选项可以只输出最重要的语句，而不输出注释及删除表语句等等
恢复SQL格式的备份文件 通过mysqldump备份的文件，如果用了- -all-databases或- -databases选项，则在备份文件中包含CREATE DATABASE和USE语句，故并不需要指定一个数据库名去恢复备份文件。
在Shell命令下：
shell> mysql –u 用户名 –p < 备份文件.sql
在mysql命令下，用source命令导入备份文件：
mysql> source备份文件.sql; //已登录mysql，用source命令
如果通过mysqldump备份的是单个数据库，且没有使用- -databases选项，则备份文件中不包含CREATE DATABASE和USE语句，那么在恢复的时候必须先创建数据库。
在shell命令下：
shell> mysqladmin –u 用户名 –p create 数据库名 //创建数据库
shell> mysql –u 用户名 –p数据库名 < 备份文件.sql
在mysql命令下：
mysql> CREATE DATABASE IF NOT EXIST 数据库名;
mysql> USE 数据库名;
mysql> source备份文件.sql;
注意：只能在cmd界面下执行source命令，不能在mysql工具里面执行source命令，会报错，因为cmd是直接调用mysql.exe来执行命令的。
4、使用xtrabackup备份数据库，并还原，并说明与mysqldump备份工具的不同。
Xtrabackup简介
Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具，是商业备份工具InnoDB Hotbackup的一个很好的替代品。 特点： (1)备份过程快速、可靠； (2)备份过程不会打断正在执行的事务； (3)能够基于压缩等功能节约磁盘空间和流量； (4)自动实现备份检验； (5)还原速度快；
Mysqldump 备份的基本流程如下： 1.调用FTWRL(flush tables with read lock)，全局禁止读写 2.开启快照读，获取此时的快照(仅对innodb表起作用) 3.备份非innodb表数据(.frm,.myi,*.myd等) 4.4.非innodb表备份完毕后，释放FTWRL锁 5.逐一备份innodb表数据 6.备份完成。
物理备份(Xtrabackup) 相对于逻辑备份利用查询提取数据中的所有记录，物理备份更直接，拷贝数据库文件和日志来完成备份，因此速度会更快。当然，无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，所以速度差异可能会进一步缩小，至少从目前生产环境来看，物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表，实际生产环境中我们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，innobackupex的基本流程如下： 1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志； 2.开启idb文件拷贝线程，拷贝innodb表的数据 3.idb文件拷贝结束，通知调用FTWRL，获取一致性位点 4.备份非innodb表(系统表)和frm文件 5.由于此时没有新事务提交，等待redo日志拷贝完成 6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的 7.获取binlog位点，此时数据库的状态是一致的。 8.释放锁，备份结束。
5、mysql主从复制的原理中启动哪些进程,写出详细过程
MySQL主从复制的基本交互过程，如下：
1、slave端的IO线程连接上master端，并请求从指定binlog日志文件的指定pos节点位置(或者从最开始的日志)开始复制之后的日志内容。
2、master端在接收到来自slave端的IO线程请求后，通知负责复制进程的IO线程，根据slave端IO线程的请求信息，读取指定binlog日志指定pos节点位置之后的日志信息，然后返回给slave端的IO线程。该返回信息中除了binlog日志所包含的信息之外，还包括本次返回的信息在master端的binlog文件名以及在该binlog日志中的pos节点位置。
3、slave端的IO线程在接收到master端IO返回的信息后，将接收到的binlog日志内容依次写入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的master端的binlog文件名和pos节点位置记录到master-info（该文件存在slave端）文件中，以便在下一次读取的时候能够清楚的告诉master“我需要从哪个binlog文件的哪个pos节点位置开始，请把此节点以后的日志内容发给我”。
4、slave端的SQL线程在检测到relaylog文件中新增内容后，会马上解析该log文件中的内容。然后还原成在master端真实执行的那些SQL语句，并在自身按顺丰依次执行这些SQL语句。这样，实际上就是在master端和slave端执行了同样的SQL语句，所以master端和slave端的数据是完全一样的。
以上mysql主从复制交互过程比较拗口，理解起来也比较麻烦，我简化了该交互过程。如下：
1、master在执行sql之后，记录二进制log文件（bin-log）。
2、slave连接master，并从master获取binlog，存于本地relay-log中，然后从上次记住的位置起执行SQL语句，一旦遇到错误则停止同步。
从以上mysql的Replication原理可以看出：
-
主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间主从数据不一致的情况。
-
如果主从的网络断开，则从库会在网络恢复正常后，批量进行同步。
-
如果对从库进行修改数据，那么如果此时从库正在在执行主库的bin-log时，则会出现错误而停止同步，这个是很危险的操作。所以一般情况下，我们要非常小心的修改从库上的数据。
-
一个衍生的配置是双主、互为主从配置，只要双方的修改不冲突，则可以工作良好。
-
如果需要多主库的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点。
