查询的实行路径：

      这个协议是半双工的，这意味着 MySQL 服务器在某个给定的时间，可以发送或接收数据，但是不能同时发送和接收。这也意味着没有办法截断消息。

      这种协议让 MySQL 的沟通简单而又快捷，但是它也有一些限制。其中一个就是无法进行流程控制，一旦一方发送消息，另一方在发送回复之前就必须提取完整的消息。这像来回抛球的游戏：在任意时刻，只有某一方有球，而且除非有球在手上，否则就不能把球抛回去（发送消息）。

      客户端用一个数据包将查询发送到服务器。这就是为什么 max_packet_size 这个配置参数对于大查询很重要的一个原因（如果查询过大，那么服务器会拒绝接收数据并且抛出一个错误）。一旦客户端发送了查询，那就意味着“球”已经不在自己手中，唯一能做的事情就是等待结果。

      但是，服务器发送的响应由许多数据包组成。服务器发送响应的时候，客户端必须接收完整的结果集。它不能只提取几行数据后就要求服务器停止发送剩下的数据。如果客户端只需要其中的几行数据，要么等待所有数据都传送完毕后丢掉不用的数据，要么就笨拙地断开连接。这两种办法都不好，这就是为什么 LIMIT 子句很重要的原因。

      还有另外一种理解方式，当客户端从服务器提取数据的时候，它认为所有数据都是从服务器“拉”过来的，但实际情况是服务器在产生这些数据的同时就把它们“推”到客户端。客户端只需要接收推出来的数据，根本没办法告诉服务器停止发送数据。

      绝大多数连接 MySQL 的类库，能让你提取完整的结果，然后缓存到内存中，或者只是提取需要的数据。默认的行为通常是提取所有数据后缓存。这很重要，因为 MySQL 只有在所有数据被提取之后，才会释放点所有的锁和资源。查询的状态会是“发送数据”。如果客户端类库一次性提取了所有的数据，那么就可以减少服务器所做的工作，让服务器可以尽可能快地完成所有的清理工作。

      大部分客户端类库可以让使用者像直接从服务器上提取数据一样处理结果，但是它实际上只是在类库的内存中处理数据。这种机制在大多数时候都工作良好，但是对于很庞大的结果集也许会需要很长的时间和很多内存。如果不缓存数据，那么就可以使用较少的内存，并且尽快开始工作。这么做的缺点就是在应用程序和类库交互的时候，服务器端的锁和资源都是被锁定的。