如果说oracle是一个踏实稳重的中年男子,那Greenplum就是一个效率很高,充满干劲却偶尔出错的年轻人,Mysql好比是红颜知己,她总是很懂你。
本着Lady First的原则,先从Mysql开始(OS:其实是近期接触Mysql较多,恰好考了Mysql的OCP,发觉很多自己不懂的地方。刚好加强下)
与其他数据库相比,Mysql虽然很轻,却足够灵活,然而灵活的意思就是很多时候会让你选择困难,哪种是最适合应用的存储引擎,是需要考究的,说到存储引擎就不得不说Mysql与其他数据库最大的区别,是在于将查询处理与数据存储引擎的读写分离。这种也就是我们可以根据不同的应用场景来决定适当的存储引擎的原因。(然而对于天秤座的我,会很纠结)
(Mysql架构图)
使用数据库,我们大多数时候都会使用SQL来进行查询操作,当我们发送一个请求的时候,数据库到底发生了什么?
(查询执行路径)
1、客户端发送一条请求到服务器
2、服务器检查buffer是否存在需要获取的数据,如果存在则立刻返回,否则执行下一步(这也是很多时候一条sql第二次执行比第一次执行耗时会短的原因)
3、服务端根据SQL解析、预处理由优化器生成执行计划
4、Mysql根据执行计划调用存储引擎的API来执行查询
5、返回结果
当然上面步骤只是抽象之后的大体流程,其实每一步都是很复杂。后面我们来慢慢理解这些。
Part1 client-server
Mysql 客户端与服务端之间的通信是采用半双工(Half Duplex),意味着在任何一个时刻,要么由服务端向客户端发送数据,要么由客户端向服务端发送数据,两个动作无法同时执行,所以我们无法也无须将消息切成一小块来发送。
这样的协议使得Mysql通信变的简单,然而去限制了Mysql对流量的控制,也就是说一端发消息之后,另一个消息端接收整个消息才能完全响应他。举个例子就是,踢皮球的时候,只有控制球的人才能将球抛出去。
客户端将一个查询请求发送到服务器,当查询时间很长返回结果很多的时候,max_allowed_packet就显的很重要了,因为当客户端发送请求之后,它只能等待服务端踢来的球了。
相反的服务端很多时候要处理多个请求,当服务端响应客户端请求时候,客户端从服务端获取数据本质是Mysql向客户端推送数据,客户端不断的接收从服务器传来的数据,客户端无法将服务端的请求断开来获取简单的几条数据,因为很多时候Mysql将数据缓存到内存之后,客户端本质是从内存中读取数据,其本质并没有减少资源的释放,所以很多时候需要加上limit来限制,而非暴力的中断:)
当查询很大的数据的时候,是否需要服务端将数据缓存到内存后,客户端读取一部分数据呢,这是值得探讨的,能够直接处理大量的数据并不一定需要缓存,这样会极大的减少内存的消耗,这个带来的缺点时,当SQL执行完成之后才能释放资源。
To be continue…
个人Blog :http://www.arriveat.top/2016/07/05/congmysqkaishi/