1、怎么处理慢查询
关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过?
在业务系统中，除了使用主键进行的查询，其他的都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。
慢查询的优化首先要搞明白慢的原因是什么？ 是查询条件没有名中索引？ 是load了不需要的数据列？还是数据量太大？
所以优化也是针对这三个方向来的，
- 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
- 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的名中索引。
- 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。
2、ACID靠什么保证的
- A原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚撤销已经执行成功的sql
- C一致性由其他三大特性保证、程序代码要保证业务上的一致性
- I隔离性由MVCC来保证
- D持久层由内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，宕机的时候可以从redo log恢复
InnoDB redo log 写盘，InnoDB 事务进入 prepare状态。
如果前面prepare 成功，binlog 写盘，再继续将事务日志持久化到binlog，如果持久化成功，那么 InnoDB 事务则进入commit状态 redo log里面写一个 commit 记录）
redolog的刷盘会在系统空闲时进行
3、什么是MVCC
多版本并发控制：读取数据数据时通过一种类似快照的方式将数据保存下来，这样读锁和写锁就不冲突了，不同的事务session会看到自己特定版本的数据，版本链
MVVC只在READ COMMITTED和REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容，因为READ UNCOMMITTED9总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。
聚簇索引记录中有两个必要的隐藏列：
-
trx_id:用来存储每次对某条聚簇索引记录进行修改的时候的事务id。 -
roll_pointer:每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录上一个版本的位置，通过它来获得上一个版本的记录信息。（注意插入操作的undo日志没有这个属性，因为它没有老版本。
已提交读和可重复读的区别就在于它们生成ReadView策略不同。
- 开始事务时创建
readview，readView维护当前活动的事务id，即未提交的事务id，排序成一个数组 - 访问数据，获取数据中的事务id（获取的时事务id最大的记录），对比readview：
- 如果在readview的左边（比readview都小），可以访问（在左边意味着该事务已经提交）
- 如果在readview的右边（比readview都大）或者就在readview中，不可以访问，获取roll_pointer，取上一版本重新对比（在右边意味着，该事务在readview生成之后出现，在readview中意味着该事务还未提交）
已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView，而可重复读隔离级别则在第一次读的时候生成一个ReadView，之后的读都复用之前的ReadView。
这就是Mysql的MVVC，通过版本链，实现多版本，可并发读-写，写-读。通过ReadView生成策略的不同实现不同的隔离级别
4、mysql主从同步原理
MySQL主从同步的过程：
MySQL的主从复制中有三个线程：master(binlog dumo thread)、slave(I/0 thread、SQL thread)，Master一条线程和Slave中的两条线程。
- 主节点binlog，主从复制的基础是主库记录数据库的所有变更记录到binlog。binlog是数据库启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
- 主节点log dump 线程，当binlog有变动时，log dump线程读取其内容并发送给从节点。
- 从节点I/O线程接受binlog内容，并将其写入到relay log文件中。
- 从节点的SQL线程读取relay log 文件内容对数据更新进行重放，最终保证主从数据库的一致性。
注意：从节点使用binlog文件+position偏移量来定位主从同步的位置，从节点会保存其已接收到的偏移量，如果从节点发生宕机重启，则会自动从position的位置发起同步。
由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库上升为主库后，日志就丢失了。由此产生两个概念。
全同步复制
- 主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。
半同步复制
- 和全同步不同的是，半同步复制的逻辑是这样的，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认位写操作完成。
5、简述Myisam和innodb的区别
MyISAM：
- 不支持事务，但是每次查询都是原子的；
- 支持表级锁，即每次操作是对整个表加锁
- 存储表的行总数；
- 一个MYISAM表有三个文件：索引文件、表结构文件、数据文件；
- 采用非聚簇索引，索引文件的数据域存储指向数据文件的指针。辅助索引与主索引基本一致，但是辅助索引不用保证唯一性。
innoDb：
- 支持ACID事务，支持事务的四种隔离级别；
- 支持行级锁及外键约束：因此可以支持写并发；
- 不存储行总数；
- 一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；
- 主键索引采用聚集索引（索引的数据域存储数据文件本身，辅助索引的数据域存储主键的值；因此从辅助索引查找数据，需要先通过辅助索引找到主键值，再访问辅助索引；最好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。
