画布 1
MySQL 的插件式架构
  Server 层
    连接器 connector
      建立、获取、维持和管理连接。注意，用户权限和连接是强绑定的，刷新了用户权限，也未必对旧连接生效。
    分析器 analyzer
      词法分析、语法分析
        1）是否使用了错误的关键字
        2）使用的关键字顺序是否正确
        3）检查数据表和数据列是否存在等
    查询缓存
      以 key、value 的形式来存储执行过的语句
        配置文件 + 运行时变量：set query_cache_type=1
        一般情况下，不建议使用查询缓存，这是因为对于一个表的更新操作，这个表上所有的查询缓存都会被清空。
因此除了很少更新的配置表外可以使用查询缓存来提供查询速度，其他的一般不建议使用查询缓存。
    优化器
      生成执行计划，包括索引选择，join 表的顺序
        得到的最优执行计划
        统计信息
          区分度低的列不应该创建索引
            优化器也可能有 bug，特别是 order by 容易触发 bug，这时候可以 force index(idx_a)或者
        代价模型
          我们肉眼看语句，也可以评估查扫描规模引发的代价
        可以通过 optimizer_trace 工具查看优化逻辑
          SET OPTIMIZER_TRACE_MAX_MEM_SIZE=268435456;
SET optimizer_trace="enabled=on";
select * from Test2 where (a between 1 and 1000) and (b between 50000 and 100000) limit 1;
select * from INFORMATION_SCHEMA.OPTIMIZER_TRACE\G
    执行器
      操作存储引擎，返回结果
  存储引擎层
    读接口
    写接口
    引擎类型
      InnoDb
      MyISAM
    执行路径如下
      1、如果查询缓存是打开的，服务器端会优先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。
      2、服务器端的分析器对SQL进行词法分析、语法分析，再由优化器从存储引擎获取统计信息，根据代价模型生成对应的执行计划(索引b就是在这个阶段完成)。
      3、服务器端根据优化器生成的执行计划，再调用存储引擎的API来执行查询，并将结果返回给客户端，具体如下
        3.1）调用InnoDB存储引擎的接口取满足”b=4“条件的第一条记录返回给执行器
          1）所在的数据页已经在内存(buffer pool)中了，则直接查询。
          2）所在的数据页不再内存(buffer pool)中
            2.1）如果此时buffer pool 的大小不足，则会淘汰buffer pool中的最久不使用的数据页为该数据页腾出位置，如果该数据页为脏页，则会在淘汰之前刷脏页到磁盘。
              1）在编写SQL语句时习惯性使用limit字段来加以限制，避免一个查询要淘汰的脏页个数太多。
            2.2）所在的数据页不再内存中，而如果此时change buffer中该数据页有更新，则会在磁盘中读取该数据页之后与change buffer中的内容进行merge作为新的数据页，然后查询结果并返回。
        3.2）执行器判断该记录中的a字段是否等于3，如果不等于则跳过，否则放入结果集
        3.3）调用InnoDB存储引擎的接口取满足“b=4”条件的下一条记录并返回给执行器
        3.4）重复第二、三步，直至循环遍历结束
        3.5）执行器将结果集返回给客户端
        1）服务器无需存储太多的结果，也就不会因为要返回太多的结果而消耗太多的内存；
2）这样的处理也让MySQL客户端第一时间获得返回的结果
    返回操作接口
  跨存储引擎的相关功能：存储过程、触发器和视图都在这一层实现