mysql内部分为：连接器，分析器，优化器，执行器和缓存查询。
连接器：用于客户端与server端进行账密连接，及权限校验。
缓存查询：一条执行的查询sql先查缓存是否存在这样的数据如果有直接返回结果（不建议使用缓存查询，命中率太低，对于更新频繁的表更倾向于操作引擎返回结果，设置query_cache_type = DEMAND 默认不使用查询缓存，我们可以在sql显示先查询缓存例如：select SQL_CACHE * from t）
分析器：对sql进行分析，sql语句是否合法，是否规范，还会校验表，字段等是否存在等
优化器：分析器执行完成之后，优化器会对sql语句进行优化如对索引的选用
执行器：执行sql语句，对于表无索引的执行流程(从表第一行开始全表扫描取到当前行做对比如果符合条件加入到结果集，直到最后一行将结果集返回)，对于有索引（通过索引数进行查找符合的加入结果集，直到不满足的行将结果集返回）

更新语句与查询语句大致相同，不一样的是更新语句涉及到两个日志模块：redo log(重做日志)，binlog(归档日志)
binlog日志：binlog是归档日志，可以追加写入，当binlog日志文件到达一定大小时候会切换到下一个文件进行追加写入。

看下这条更新语句如何执行

2.WRITESET表示对于事务涉及更新的每一行，计算出这行的hash值，组成集合writeset，如果两个事务没有更新同一行，也就是两个writeset没有交集，就可以并行。
3.WRITESET_SESSION表示在WRITESET的基础上多了一个约束，即在主库上同一个线程先后执行多个事务，在备库执行的时候也要保证相同的执行顺序。

18.主从切换复制数据出现错误如何解决

19.读写分离有哪些坑

解决主从数据不一致，过期读的方案

1.对于要求实时性比较高的数据，主从延迟导致主从数据不一致，可以将这部分查询数据放到主库上读。
2.在读从库时候可以Sleep休眠一下，可以解决但是是不靠谱，不好控制休眠时间。
3.使用判断主备是否有延迟在进行查询从库，show slave status 可以查到second_behind_master值如果为0，说明无延迟。单位是s级别的，也不是很准确
3.semi-sync方式，事务提交主库生成的binlog发送给从库，从库收到binlog以后，会发给主库一个ack表示我已收到。主库收到这个ack时候响应给客户端事务完成。弊端：一主一从方案满足，但是一主多从方案可能也会产生过期度。

20.查询数据那么多不会OOM吗？

InnoDB保存数据在主键索引上的，全表扫描实际上扫描的是主键索引，查到的每一行都直接放入到结果集返回给客户端，获取到数据放入到net_buffer中，大小可通过参数net_buffer_length控制，默认16k，当net_buffer写满调用发送接口发送给客户端，发送成功情况net_buffer继续读取数据。
buffer pool淘汰数据页策略：使用的LRU算法，淘汰最久未使用的数据。将Buffer pool的链表分成yong区和old区比例5:3，如何淘汰一个数据页，有新的数据页需要加入到buffer pool中需要淘汰处于old区链表的尾部的数据页，
yong区数据被访问直接将该数据页加入到yong链表头部，
old区数据页被访问需要做判断，如果这个数据页在old区超过1s就需要将该数据页移动到yong区的头部，如果短于1s位置不变。

使用join有这几种方式
Blocked Nested-Loop join算法：数据读到内存（join_buffer_size 控制内存大小）进行判断比较，如果数据过多可以将数据分块读取。(注意项：如果驱动表是大的冷数据表，如果join_buffer不够大会全表扫描多次，不仅会导致IO压力大还有一个致命的问题，多次扫描会导致buffer pool中的yong区数据页会被淘汰，导致查询频繁的数据页需要重新从磁盘上扫描出来放入buffer pool中)
INdex Nested-Loop join：使用索引进行查询比较效率高，扫描的行数较少。

22.为什么自增id不是连续的？

产生这种不连续的原因有，1.一个事务执行发生异常回滚了，在这个事务执行过程中有其他事物对自增主键incr了，为什么发生回滚不回滚id，如果也会滚id导致下次增加插入数据主键冲突
2.当执行批量插入的时候，为了避免其他事物需要等待，mysql在批量插入引入事先申请自增的id，如：第一次插入申请2个，第二次插入申请4个每次申请都是上次申请的2倍，这样就会导致最后一次申请的id过多，导致出现较大的id不连续。