本文以UPSQLProxy2.4.0中的关键消息流处理为例，介绍MySQL通信协议及其与客户端的关系。MySQLCommunicationProtocol协议介绍当执行一个MySQL查询，如“select*fromtest”时，MySQL的响应包称为ResultSet，它是一组逻辑包（协议包），如图1所示。它由两部分组成parts:1.Metadata，包括以下数据包：-Field_Count：列的个数-Field：列的描述，一般为多个-Eof：用于在描述列信息时标记一段数据发送结束或发送数据时。在以后的版本中，这个数据包被抑制了。2.行数据，包括：-Row：一行数据的内容，会出现多行-Err：描述错误，发生错误时，是最后一个逻辑包或-OK：在高版本协议中，用于替换Eof包传递更多信息图1MySQL结果集消息结构客户端库接口介绍本MySQLCAPI提供了两套函数接口：-mysql_store_result/mysql_stmt_store_result-mysql_use_result一般来说，这两套接口的区别在于：-mysql_store_result/mysql_stmt_store_result：将结果存入应用内存-mysql_use_result：将数据保存在tcpbuffer或数据库服务器端但是从通信过程来看：-mysql_store_result/mysql_stmt_store_result：需要等待所有数据传输完成，并且客户端解析End-mysql_use_result:简单的说，只要获取到行数据包，就可以将数据返回给上层API。因此，我们内部调用mysql_use_result流处理。流处理有两大优势：-应用层响应更快，因为它不需要等待结果集被收集-内存管理更可控，可以避免客户端内存不足。在mysqlclient和mysqldump命令中，有如下参数：---quik/-q，即使用mysql_use_result进行流式处理，可以避免mysqldump数据量大，oomJDBC在设计上有更高的封装性。一般来说，它的逻辑和CAPI的mysql_store_result/mysql_stmt_store_result处理逻辑是一样的，但是有两种方法可以将其转换为流处理方式：-代码层面：prepareStatement第二个和第三个参数设置为ResultSet.TYPE_FORWARD_ONLY，ResultSet。CONCUR_READ_ONLY-JDBCURL设置（不修改代码）：添加参数useCursorFetch=true&defaultFetchSize=-2147483648（该方法在不同版本的jdbc驱动上表现不同，不推荐）API与协议关系分析如图2：▲图2API及协议分析UPSQLProxy中间件设计在UPSQLProxy2.4.0之前采用阻塞模式，即将结果集收集到多个后端后，再响应给用户，这样有两个缺点：-响应延迟延长了Proxy层的内存控制，导致生产环境不支持sub下大于10万行的数据量-数据库返回UPSQLProxy2.4.0实现流处理。简单来说，就是尽快将行信息以流的形式发送给客户端，而不是等待中间件收集。逻辑如图3所示：▲图3UPSQLProxyProcessingStreaming是指在分库场景下，每个数据节点都会被并发访问。当获得完整的元数据后，可以立即返回给请求者。收到行数据后，可以及时返回给请求者。降低中间件的内存需求，相应的提高客户端的速度。总结本文介绍银联自研中间件UPSQLProxy较早的一次关键功能迭代，希望能让大家感受到MySQL协议的魅力。福利时间（目前作者在投递中会有机会内参🙌🏻🙌🏻🙌🏻）：中国银联云计算中心社交招聘职位正在招聘目录中，目前开放招聘的职位如下：1.运维服务2.系统运维3.操作系统开发4.数据库开发（云计算方向）5.开源组件6.综合秘书前往浏览器或点击阅读原文】https://join.unionpay.com选择“社会招聘”分类投放。【注：内推推荐人请填写周家静，工号：01362912】
