mysql的一些小见解

今天看了一篇博文，里面有张经典的mysql的逻辑架构图，感觉比较有意思，放到文章中，大家看下：

mysql的逻辑架构整体分为三层，最上层是客户端，但是并非MySQL所独有，诸如：连接处理、授权认证、安全等功能均在这一层处理。

完事第二层就是核心服务层。查询解析、分析、优化、缓存、内置函数(比如：时间、数学、加密等函数)等，还有所有的跨存储引擎的功能，诸如：存储过程、触发器、视图等核心服务都在这一层实现。

最下层呢，就是存储引擎，它负责MySQL中的数据存储和提取。和Linux下的文件系统类似，每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信，这些API接口屏蔽了不同存储引擎间的差异。

完事我们再来看一张mysql的select过程的图：

众所周知，要想提高mysql的查询性能，最根本的就是搞懂mysql是如何优化和执行查询的。完事咱们借用一句话哈：很多的查询优化工作实际上就是遵循一些原则让mysql的优化器能够按照预想的合理方式运行而已。

是不是感觉有点小尴尬？？？话虽如此，但是具体的又该怎么做呢？咱们不妨回过头来看上面的图片，来好好理解下。

完事咱们来看下mysql的客户端/服务端通信协议。其实，mysql客户端/服务端通信协议是“半双工”的性质，我们可以这样理解：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生。一旦一端开始发送消息，另一端要接收完整个消息才能响应它，所以我们无法也无须将一个消息切成小块独立发送，也没有办法进行流量控制。

客户端用一个单独的数据包将查询请求发送给服务器，所以当查询语句很长的时候，需要设置max_allowed_packet参数。但是需要注意的是，如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常。

与之相反的是，服务器响应给用户的数据通常会很多，由多个数据包组成。但是当服务器响应客户端请求时，客户端必须完整的接收整个返回结果，而不能简单的只取前面几条结果，然后让服务器停止发送。因而在实际开发中，尽量保持查询简单且只返回必需的数据，减小通信间数据包的大小和数量是一个非常好的习惯，这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。

好啦，咱们本次就记录到这里了。太具体的，我感觉不是文字写得出来的（词穷了）。

如果感觉不错的话，请多多点赞支持哦。。。