前言
准备整理mysql的基础篇了，前面整理了sql语句序列的的《sql 语句系列（八百章）》，感觉很多用不上，就停下来了，后续还是会继续整理。
mysql 基础篇主要是对一些基础进行整理，同时望请大佬能够指点一二。之所以整理mysql，而不是sql server，一个是因为sql server 相对来说稳定，同时sql server 水很深，后续会整理一些被sql server 折磨的经历。
这里说一句公道话，sql server 从综合来说的确比mysql 强，不然人家也不好意思收费。但是我们很多场景mysql 就足够了，mysql 效率也不低，因为不用考虑到很多的场景，故而少量数据查询可能比sql server 要好。
其实谈那个性能怎么样，怎么怎么好，是没有意义的，主要看怎么用吧，一个设计不好的数据库，引擎再怎么好，也是泥坑。
好吧，下面就开始整理一下，比较基础。
正文
网上有很多图说明mysql的内部结构，我这里重新化了一下:
好像市面上比较喜欢聊的InnoDB就属于存储引擎，存储引擎 可以说是数据库的核心。
如果把mysql 比作一台电脑的话，那么连接器就是登陆界面。 查询缓存就是内存。 分析器和优化器就相当于编译器。 执行器就相当于cpu。存储引擎就相当于文件系统。
还是那句话吧，任何一件东西都不是凭空产生，肯定有前面的借鉴之处，这里面就借鉴了一些电脑整体架构的东西，又是一个套娃系统。
先来介绍一下连接器。
连接器，既然是连接的，那么要保证两个问题，一个是安全，一个是快速。
快速呢，这个可以通过高效的协议搞定。
安全呢，通过验证机制搞定。
mysql 的这一套安全机制和连接协议其实是比较简单的，这里不细说，可以百度看看。
如果我们连接上了，那么我们可以去进行查看:
在写完show processlist后面我又加了一个；,这条语句才执行了。
里面查询到两个，第一个呢，是我使用工具进行连接，状态是sleep。第二个是我们命令行界面进行了连接。
我这样打开一个库:
那么我们再show processlist 一下:
又进行了一个连接。
那么这里想说明的是，其实一个应用的连接数其实比我们想象的多。
如果我们的客户端和服务器的连接一直sleep 状态，那么8小时后又会断开。
因为应用一般每秒处理很多请求，故而请求非常多，连接数自然非常多了，而mysql的连接数是有限的，因为人家要维持这么多连接也不容易。
解决方案有两个:
-
连接池。
-
长连接。
连接池 比较好理解哈，就是会维护一套自我自己，不会连接太多的数量，反复利用。
长连接，就是像上面一样进行连接，不断开。
长连接有一个坏处，那就是应用程序和mysql 的连接，并不是http这种无状态的，它可能你不断的执行的时候给你记上一些小本本，这样你的连接对象就越来越大了。
-
定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开
连接，之后要查询再重连。 -
如果你用的是MySQL 5.7或更新版本，可以在每次执行一个比较大的操作后，通过执行
mysql_reset_connection来重新初始化连接资源。这个过程不需要重连和重新做权限验证，
但是会将连接恢复到刚刚创建完时的状态。
这里面有个查询缓存，这个是来查询如果这条语句前面查询过，那么就直接去缓存里面的值。
上图中缓存没有很好的画好，其实就是查询的时候判断是否有缓存，直接是当前语句的hash值，查询hash表看是否命中，如果这条语句的列的顺序不同，都不会命中。
同样，当启动了缓存，那么当查询完的时候会将该语句的hash值和查询结果放入缓存中。
网上很多人提及到不要开启，因为如果查询语句，只有表发生了改变，这个缓存就失效了，而表很多时候都会进行更新。
也就是说要维护这套缓存机制受益不如不用。
个人觉得还有一个重要的原因，那就是现在强大的缓存架构，如redis 这样的缓存数据库。让应用去觉得哪个去缓存是更好的，所以显得鸡肋了。
分析器：这个比较好理解了，比如我们写一条select * from student,这个东西呢，mysql 根本执行不了，是为了让我们的人类看的懂罢了。
这时候就解析成执行器能够识别的语句。
优化器: 根据mysql能够识别的语法，用一些算法进行优化，比如说索引、表与表的连接。有些可能是负优化，因为算法不可能照顾每一种场景。我们做的就是去迎合优化。
执行器: 这个时候判断是否对这个表有相应的权限，比如说查询、更新权限等，这里就会进行权限缓存，所以这也是我们的连接对象会大的原因之一，这也是为啥我们断开连接新的权限才会生效的原因。
如果权限通过，那么就很好办了，就进行执行，当然其中一些操作会调用到存储引擎，这些后面介绍。
结
以上只是个人重新整理一下mysql，后续一直整理更新。
下一节，日志介绍。