1.你目前接触的MySQL版本是什么？除了官方版本，还接触过其他的MySQL分支版本吗？
三个流行的MySQL分支：Drizzle、MariaDB、Percona Server(包括XtraDB引擎)。
MariaDB不仅是MySQL的替代品，主要是创新和提高了MySQL自有技术。新功能有：multi-source replication多源复制、表的并行复制、galera cluster集群、spider水平分片、TokuDB存储引擎。
XtraDB是InnoDB存储引擎的增强版，可用来更好地发挥最新的计算机硬件系统性能，还包含在高性能模式下的新特性。它可以向下兼容，因为它是在InnoDB基础上构建的，所以有更多的指标和扩展功能。而且它在CPU多核条件下，可以更好地使用内存，将数据库性能提到更高。
Drizzle与MySQL的差别较大，并且不能兼容，如果想运行此环境就需要重写一些代码。
2.MySQL主要的存储引擎MyISAM和InnoDB的不同之处？
事务的支持不同：InnoDB支持事务，MyISAM不支持事务；
锁粒度：InnoDB行锁应用，MyISAM表锁；
存储空间：InnoDB既缓存索引文件又缓存数据文件，MyISAM只能缓存索引文件；
存储结构：InnoDB所有的表都保存在同一个数据文件里，即.Ibd，MyISAM数据文件的扩展名为.MYD myData，索引文件的扩展名是.MYI myIndex；
统计记录行数：InnoDB没有保存表的总行数，select count() from table会遍历整个表，消耗相当大；MyISAM保存有表的总行数，select count() from table会直接取出该值。
3.介绍一下InnoDB的体系结构
MySQL的体系结构分为MySQL的server层和存储引擎层两部分。
InnoDB的体系结构：内存、线程、磁盘。
内存中包含insert_buffer、data_buffer、index_buffer、redo_log_buffer、double_write。
内存刷新到磁盘的机制：redo log buffer、脏页、binlog cache的刷新条件。
各种线程的作用**：master_thread、purge_thread、redo log thread、read thread、write thread、page cleaner thread。**
磁盘中存放的数据文件：redo log、undo log、binlog。
4.MySQL有哪些索引类型？
从数据结构角度：B+tree索引、hash索引、fulltext索引。
从存储角度：聚集索引和非聚集索引。
从逻辑角度：primary key、normal key、单列、复合和覆盖索引。
5.MySQL binlog有几种格式？生产中你用哪种？各自有什么特点？
第一种：statement格式
优点：不需要记录每一行的变化，减少了binlog日志量，节约了I/O，提高了性能。
缺点：当使用一些特殊函数，或者跨库操作时容易丢失数据。
注：生产中不建议使用。
第二种：row格式
优点：清晰记录每行的数据信息，不会出现跨库丢数据的情况，安全性非常高。
缺点：当内容记录到日志中时，都将以每行的修改来记录，会产生大量的binlog，网络开销也比较大。
注：生产中推荐使用。
第三种：mixed格式
MySQL 5.1的一个过度版本，DDL语句会记录成statement，DML会记录成row。
注：生产中不建议使用。
6.MySQL主从复制的具体原理是什么？
主服务器把数据更新记录到二进制日志中，从服务器通过I/O thread向主库发起binlog请求，主服务器通过I/O dump thread把二进制日志传递给从库，从库通过I/O thread记录到自己的中继日志中。然后通过SQL thread应用中继日志中SQL的内容。
7.MySQL主从延迟的原理是什么？如何监控主从延迟，如何解决主从延迟问题？
主库可以并发写入，但从库只能通过SQL thread完成任务，这是出现主从延迟的最核心原因。
（1）MySQL主从之间的同步本来就不是实时同步的，是异步的同步，即主库提交事务之后，从库才执行一遍。
（2）在主库上对没有索引大表的列进行delete或者update的操作。
（3）从库的硬件配置没有主库的好，经常忽略从库的重要性。
（4）网络抖动导致I/O线程复制延迟。
对于监控主从延迟，可以通过第三方工具（precona-toolkit）中的pt-heartbeat命令进行主从延迟监控。
传统方法，通过比较主从服务器之间的position号的差异值。还可通过查看seconds_behind_master估算一下主从延迟时间。
解决主从延迟的方法：
（1）使用MySQL 5.7的并行复制功能。主库并行执行SQL语句，从库也可以通过多个workers线程并发执行relay log中主库提交的事务。想要开启MySQL 5.7的并行复制，可以在从库设置参数slave_parallel_workers>0，并把5.7版本中新添加的slave_parallel_type参数设置的LOGICAL_CLOCK。该参数有DATABASE和LOGICAL_CLOCK两个值。MySQL 5.6 默认是DATABASE。
（2）可以采用PXC架构，在这种架构下可以实现多节点写入，达到实时同步。
（3）业务初期规划时，就要选择合适的分库、分表策略， 避免单表或者单库过大，带来额外的复制压力，从而带来主从延迟的问题。
（4）避免一些无用的I/O消耗，可以增加高转速的磁盘、SSD或者PCIE-SSE设备。
（5）阵列级别要选择RAID10，raid cache策略要采用WB，坚决不要采用WT。
（6）I/O调度要选择deadline模式。
（7）适当调整buffer pool的大小。
（8）避免让数据库进行各种大量运算，要记住数据库只是用来存储数据的，让应用端多分担些压力，或者可以通过缓存来完成。
8.数据库中的双一是什么？
一个是sync_binlog=1，另一个是innodb_flush_log_at_trx_commit=1。
innodb_flush_log_at_trx_commit和sync_binlog两个参数是控制MySQL磁盘写入策略以及数据安全性的关键参数。
innodb_flush_log_at_trx_commit设置为1，每次事务提交时，MySQL都会把log buffer的数据写入log file，并且刷到磁盘中。
sync_binlog=N（N>0），MySQL在每写N次二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中。
