作者简介：周家晶，中国银联·云计算中心。作者长期负责中国银联自研中间件UPSQL Proxy和分布式数据库UPDRDB的研发与设计工作。
本文以UPSQL Proxy 2.4.0中关键的报文流式处理为例，介绍MySQL通信协议，以及与客户端的关系。
在执行MySQL查询，如“selecet * from test”时，MySQL的应答包被称为ResultSet，其为一组逻辑包(协议包)，如图1所示包含两个部分：
- Eof：在列信息描述，或数据发送完毕时候，用以标记一段数据的发送结束。在较高版中，该数据包被取消。
- Err：描述错误，出现错误时，为最后一个逻辑包
- OK：在较高版本协议中，用以替换Eof包，用以传输更多信息
客户端库接口介绍
- mysql_store_result/mysql_stmt_store_result
- mysql_store_result/mysql_stmt_store_result: 将结果存储在应用内存
- mysql_use_result: 数据保存在tcp buffer或数据库server端
- mysql_store_result/mysql_stmt_store_result: 需要等待所有数据传输完毕，并且客户端解析完毕
- mysql_use_result: 简单而言只要得到row数据包，就可以向上层api返回数据
所以，我们内部将mysql_use_result称为流式处理，流式处理有2大优点：
在mysql客户端以及mysqldump命令中，有如下参数：
- --quik/-q，即使用mysql_use_result，进行流式处理，可以避免mysqldump大数据量下oom
JDBC在设计上封装性更高，一般而言其逻辑与CAPI的
mysql_store_result/mysql_stmt_store_result处理逻辑一样，但有2个方法可以将其转换为流式处理模式：
- 代码层面：prepareStatement第2、3个参数设置为ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY
- JDBC URL设置(不修改代码)：增加参数useCursorFetch=true&defaultFetchSize=-2147483648 (该方法在不同版本的jdbc驱动上表现有区别，不建议采用)
在UPSQL Proxy 2.4.0以前使用的是阻塞模式，即往多个后端收齐结果集后，再向用户应答，这样有2个缺点：
- Proxy层内存控制，导致生产环境不支持大于分库下10w行以上数据量返回
UPSQL Proxy 2.4.0实现了流式处理，简单而言就是，将行信息尽快以流的形式发给客户端而不是等中间件收齐后发送，逻辑如图3所示：
即在分库场景下，会并发访问各个数据节点，当得到一个完整的元数据后，就可以立刻返回给请求方，之后接收到行数据后，都可以及时的返回给请求方，以此降低中间件的内存需求，同时提高客户端的相应速度。
总结
本文介绍了银联自研中间件UPSQL Proxy早前的一次关键功能迭代，希望能让大家感受到MySQL协议的魅力。
福利时间（目前投递会有作者的内推机会哦 🙌🏻🙌🏻🙌🏻）：
中国银联云计算中心社会招聘岗位正在火热招录中，目前开放投递的岗位如下：
1、运营服务
2、系统运维
3、操作系统开发
4、数据库开发（云计算方向）
5、开源组件
6、综合文秘
有意向者可打开链接【可复制到浏览器或者点击阅读原文】 https://join.unionpay.com 选择“社会招聘”分类进行投递。【注：内推请填写 周家晶及工号：01362912为推荐人】
🔥 直播来了 📢
