1、怎么处理慢查询

关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过?

在业务系统中，除了使用主键进行的查询，其他的都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。

慢查询的优化首先要搞明白慢的原因是什么？是查询条件没有名中索引？是load了不需要的数据列？还是数据量太大？

所以优化也是针对这三个方向来的，

2、ACID靠什么保证的

InnoDB redo log 写盘，InnoDB 事务进入 prepare状态。
如果前面prepare 成功，binlog 写盘，再继续将事务日志持久化到binlog，如果持久化成功，那么 InnoDB 事务则进入commit状态 redo log里面写一个 commit 记录）

redolog的刷盘会在系统空闲时进行

多版本并发控制：读取数据数据时通过一种类似快照的方式将数据保存下来，这样读锁和写锁就不冲突了，不同的事务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生成策略的不同实现不同的隔离级别

MySQL主从同步的过程：

MySQL的主从复制中有三个线程：master(binlog dumo thread)、slave(I/0 thread、SQL thread)，Master一条线程和Slave中的两条线程。

注意：从节点使用binlog文件+position偏移量来定位主从同步的位置，从节点会保存其已接收到的偏移量，如果从节点发生宕机重启，则会自动从position的位置发起同步。

由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库上升为主库后，日志就丢失了。由此产生两个概念。

全同步复制

半同步复制

MyISAM：

innoDb：

支持ACID事务，支持事务的四种隔离级别；
支持行级锁及外键约束：因此可以支持写并发；
不存储行总数；
一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；
主键索引采用聚集索引（索引的数据域存储数据文件本身，辅助索引的数据域存储主键的值；因此从辅助索引查找数据，需要先通过辅助索引找到主键值，再访问辅助索引；最好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。