SQL 的奇妙旅程
一条SQL的奇妙旅行
工作中我们经常查询数据库,用一个查询,得到想要的数据。可有想过,我们得到答案经过了哪些磨难？经历了哪些诱惑？
本节将以一个sql的执行过程来了解 MySQL 整体架构，对mysql有一个全面，清晰的认知，for造航母。
开始旅行
第一关: 连接器,客户端发送一条查询给服务器,包含客户端相关信息(IP,用户,密码);服务器完成验证（报告太君,自己人,可以放行）。
第二关: 查询缓存,执行查询语句的时候,会先查询缓存,我们会发现某个查询，查询第二次的时候非常快便是这个原因(MySQL8.0 废除这个功能,太鸡肋)。
第三关: 解析器,第一步解析你的语法（单词别写错了，写错了我可不会干活），主要是关键字；第二步解析涉及到的对象是否存在，人都没有，跟个空气聊啥呢；第三步，涉及到的对象用户是否有对应的权限（哎呀，不给钱就不给摸，不给摸）。
第四关: 优化器,当语法与语义都没有问题权限也匹配，此时数据库便开始真正为你服务了，根据一定得算法规则，对你的查询进行优化，寻找最优的执行计划（这就跟找老婆一样，国家分配的跟自己找的肯定还是不一样的，多数情况下，还是自己找的好）。
第五关: 执行器，先判断数据是否在缓冲池中，若在，直接返回，若不在，则先从磁盘文件中加载到内存（反正今天要定了）。
第六关：数据返回，数据返回是一边查询，一边返回，并不是一次返回，虽然看上去是一下突然返回的（这就好像‘学外语’，你看见的不一定就是真的）。
旅行图如下
MySQL 体系结构图
最外层客户端：各种语言API连接数据库
第一层：连接层，包含连接池，身份验证，查询缓存
第二层：核心服务层，解析器，优化器，跨存储引擎的函数，存储过程，触发器，视图，SQL接口，管理服务工具组件
第三层：存储引擎层，不同存储引擎即数据的存取方式不同
第四层：文件系统，底层存储数据的磁盘
介绍一哈 InnoDB 存储引擎
Innodb 存储引擎3大特性
自适应hash索引 B+树的高度一般为3~4层,故需要3~4次的查询，如果观察到建立哈希索引可以带来速度提升,则建立哈希索引,称之为自适应哈希索引(Adaptive Hash Index,AHI) AHI是通过缓冲池的B+树页构造而来,因此建立的速度很快,而且不需要对整张表构建哈希索引。 InnoDB存储引擎会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引 --来自INNODB 技术内幕（人工智能赶脚有没有）
缺点: 跟普通索引一样需要额外开销维护。
对于非聚集类索引的插入和更新操作，不是每一次都直接插入到索引页中，而是先插入到内存中。具体做法是：如果该索引页在缓冲池中，直接插入；否则，先将其放入插入缓冲区中，再以一定的频率和索引页合并，这时，就可以将同一个索引页中的多个插入合并到一个IO操作中，大大提高写性能。（一定是非聚集索引）
缺点：可能导致数据库宕机后实例恢复时间变长，占用太多缓冲池内存
当mysql将脏数据flush到data file的时候, 先使用memcopy 将脏数据复制到内存中的double write buffer ，通过double write buffer再分2次，每次写入1MB到共享表空间，然后马上调用fsync函数，同步到磁盘上，避免缓冲带来的问题。（前俩个是提升性能，双写主要保证数据页的可用性）