MYSQL开篇：mysql的体系结构

前言：本文为mysql的开篇文章，后边陆续会写mysql一系列的知识。主要记录了最近一段时间学习的东西并分享给大家。

一条查询语句的执行流程：

客户端发起连接，首先回去缓存区查询看能否命中，命中则直接返回。
没命中进行下一步解析器，解析词法和语法是否有误。
无误进行下一步交给预处理器，做语义分析权限处理。
然后给优化器，优化器会找到最好的执行计划，然后给执行器执行计划。
执行器会调用存储引擎的api查找数据，返回给执行器。执行器会先写入到缓存区，最后返回数据给客户端。

连接

mysql的通信类型：支持同步和异步。一般我们都是同步的类型。
连接方式：支持长连接和短连接。通常我们都是使用的长连接，减少创建和销毁的性能消耗。

缓存模块（query cache）

默认关闭的，mysql自带的缓存不推荐使用，因为它的应用场景实在是太苛刻了。比如你sql中多了个空格，它就会认为你这不是同一条sql，就不从缓存中查了。再比如，如果缓存中的一条数据发生变化了，整个表的缓存都会失效的。所以说。不推荐使用mysql自带的缓存。

解析器（parser）

解析器的主要作用就是对词法和语法的解析，看你的sql是否符合规约。
词法解析：会把一条sql打碎成各个单词,如下图：

语法解析：就是校验sql语法是否正确。

预处理器

处理语义分析，比如别名用的对不对等，还有分析权限，执行update时检验是否有update的权限。

优化器（optimizer）

要知道，一条sql语句，他的执行方式是有多种的，只要结果不变，他的查询方式条件可以随意改变的。类似于程序中代码的执行顺序样，只要保证不改变执行结果的前提下，执行的顺序可以被改变的。
比如，一条查询语句同时使用到多个索引了，那么具体要用哪个索引呢，这就是优化器来决定的了。优化器会找出多个执行计划，并计算出它们的执行成本，然后优化器会根据成本找到一个最优的执行计划。
注意：虽然优化器很nb了，但他也不是万能的，不是所有的垃圾sql他都能优化的。所以说，我们还有写一手漂亮的sql。给优化器优化他可能就会更漂亮了。

模块分析总结

mysql的存储引擎

存储引擎以表为单位，一张表对应一个存储引擎。
mysql支持哪些存储引擎，我们可以用命令：show engines;来查看。

我们用的最多或者见过最多的就是InnoDB和MyISAM了。
5.5版本之前MyISAM是默认的存储引擎，而5.5之后InnoDB成为默认的存储引擎。
二者的区别：
1.InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；
2. InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败；
3. InnoDB 是聚集索引，MyISAM 是非聚集索引。聚集索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。（我们在mysql的目录中可以看到，myisam的表有两个文件’.MYD’存放数据和‘.MYI’存放索引。而InnoDB 的表只有一个文件‘.ibd’数据和索引都在这个文件里。后续在索引部分会细说这些东西）
4. InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
5. InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；

>>下一遍：简单分析InnoDB存储引擎的内存架构