mysql处理sql有两种类型，第一种就是上一篇介绍的文本类型sql(mysql通信协议 -- 语句执行)，这种sql执行在mysql服务端需要经历语法解析、sql优化、执行一系列过程， 而有些时候sql类型是通用的，只是where条件或新增、修改的数据不同，如果每次都直接传递文本sql，每次sql执行都会经历上述过程，这样其实存在一定的性能浪费。
sql预处理可以通过一次编译多次调用，使用占位符的方式替换值，交由mysql语法解析、优化预处理，客户端每次调用只需传递值即可，提升了sql执行过程中的效率，预处理还有个好处就是可以防止sql注入。
和text_protocol类似，由客户端发送COM_STMT_PREPARE数据包开始，mysql返回数据预处理语句id和sql中涉及到的字段元数据，或者ERR_Packet报错。
COM_STMT_PREPARE_OK：
可以看到packet里包含该语句经过处理后在mysql里面唯一标示statement_id，调用的时候给发送这个id和数据就行了，其中同时也返回了查询的字段数，num_params是需要传递的数据个数，等同占位符的个数，后面还有告警信息字段元数据，字段元数据和text_protocol一样，见上一篇。
COM_STMT_EXECUTE：
客户端需要调用预处理的语句并传递数据进行操作时就发送COM_STMT_EXECUTE包，图中可以看到statement_id，也就是COM_STMT_PREPARE_OK中返回的statement_id，这是语句的唯一标示，最后面就是传递占位符需求的数据，都是根据占位符对应字段类型进行处理，占位符对应字段类型mysql不会直接返回，只会返回一个统一的text类型，需要在客户端首先获取元数据进行处理。
Binary Protocol Resultset：
mysql处理后返回数据的packet，其中也包含字段元数据信息，数据返回跟text_protocol的也类似，一行数据一个packet，ProtocolBinary::ResultsetRow见下图:
数据返回根据字段类型进行判断就行了，这里简单介绍两种类型的解析方式(整型和字符串类型)，可以看到数据存放的方式时binary<var>，是通过另外的位置定义来获取长度的方式，整型中的int占用4bytes就直接读取4bytes就行，如果是字符串类型（text），就需要判断长度，如果<=255就读取1bytes来获取后面数据内容的长度，再详细的内容等后面说binlog数据解析的时候再全面介绍。
在发送和接收的数据包中都看到有个null_bitmap类型， 这是拿来判断对应字段是否为null的位图信息，占用字节数根据字段数据计算((column_count +7) / 8)，上面的图中有个加2，其实并没有，举个例子，比如有9个字段，而第9个字段为null，它的index应该是8，因为下标是从0开始的，位图计算方式如下：
int((9 +7) / 8) = 2
null_bitmap = [00] [00] 两个字节的空数据
bytes_pos = int(8 / 8)
bit_pos = int(8 % 8)
null_bitmap[bytes_pos] |= 1 << bit_pos
sql预处理协议packet主要的东西大概就这些，而其中返回的OK_Packet、ERR_Packet、EOF_Packet这些在这里并未进行说明，因为这都是通用的，同样的结合脚本进行验证，见github自行下载测试验证(只做了字符串和整型数据的测试)
