实现一个MySQL代理中间件，本质上是在客户端和数据库服务器之间插入一个透明的数据转发层。要让它真正有用，而不是仅仅做一个TCP端口转发，就必须理解MySQL的通信协议。这篇文章会从一个最简单的TCP转发开始，逐步加入协议解析能力，最终实现一个能够记录SQL语句并正常转发查询结果的简单代理。
MySQL协议基础：数据包格式与连接阶段
MySQL客户端与服务器之间的通信全部通过数据包（Packet）完成。每个数据包由两部分组成：一个4字节的包头和紧随其后的负载数据。包头的前3个字节表示负载长度（小端序），第4个字节是序列号（sequence id）。序列号从0开始，每发送一个包递增1，服务器回复时使用相同的序列号。负载长度最大为0xFFFFFF（约16MB），更大的数据会被拆分成多个包。
连接建立后，服务器会主动发送第一个数据包，称为握手初始化包（HandshakeV10）。这个包包含了服务器版本、连接ID、随机盐值等关键信息。客户端收到后，需要回复一个握手响应包，其中包含用户名、认证数据等信息。如果认证成功，服务器返回OK包；认证失败则返回ERR包。之后才进入命令阶段，客户端可以发送查询、插入等命令。
理解这个阶段对代理实现非常关键。代理在转发流量时，必须知道当前处于哪个阶段，才能在必要时对数据包进行修改或记录。例如，如果代理想要注入一个额外的初始化参数，就需要在握手阶段修改服务器的握手包，并在客户端响应中做相应调整。对于简单的日志代理，我们至少需要识别出认证阶段结束、开始发送命令的时机。
实际开发中，很多人会忽略序列号的维护。代理在两个独立的TCP连接之间转发数据时，每一侧的序列号是独立计算的。如果代理只是原样复制字节，序列号并不会出错；但若代理需要重写或插入数据包，就必须重新计算对应的序列号，否则客户端或服务器会直接断开连接。
实现核心：TCP转发与数据包边界识别
代理的基础架构是两个TCP连接：一个面向客户端的监听连接，另一个是代理主动发起到后端MySQL服务器的连接。收到客户端数据后，代理读取并解析数据包，然后将原始字节写入后端连接；后端响应数据同样被读取、解析并转发给客户端。这个过程中最重要的任务之一就是正确地切分数据包。
由于TCP是流式协议，数据可能分多次到达，也可能多个数据包粘在一起。我们需要一个缓冲区，持续读取数据，然后按照MySQL包头中的长度字段来切分。下面是一个使用Go语言实现的读取完整MySQL数据包的函数示例：
// readPacket 从连接中读取一个完整的MySQL数据包
func readPacket(conn net.Conn) ([]byte, error) {
header := make([]byte, 4)
if _, err := io.ReadFull(conn, header); err != nil {
return nil, err
}
length := int(header[0]) | int(header[1])<<8 | int(header[2])<<16
payload := make([]byte, length)
if _, err := io.ReadFull(conn, payload); err != nil {
return nil, err
}
// 返回完整包，包含4字节包头和负载
return append(header, payload...), nil
}
这个函数使用io.ReadFull确保读取到指定长度的数据，避免了半包问题。获得一个完整数据包后，就可以解析负载的第一个字节来判断包类型。例如，0x00代表OK包，0xFF代表ERR包，0xFE在某些场景下代表EOF包，而命令阶段的第一个字节则是命令类型（如0x03是COM_QUERY）。
代理的转发循环通常包含两个goroutine：一个负责客户端到后端的方向，另一个负责后端到客户端的方向。每个方向独立进行读取、解析、转发。对于只需要日志记录的代理，我们可以只解析客户端发往服务器的包，从中提取SQL语句。需要注意的是，SQL语句可能被拆分到多个数据包中（当SQL超过16MB时），但实际场景中单条SQL多数情况下远小于该限制。
处理认证与查询命令的细节
在连接建立后的认证阶段，代理会转发一系列数据包。如果代理不需要修改认证信息，最安全的做法是完全透明地转发所有数据，直到认证成功。但为了后续能够解析命令，代理必须记住连接的状态。我们可以用一个简单的状态机来实现：初始状态为等待握手，收到客户端的握手响应后，等待服务器的认证结果。一旦收到OK包，状态切换为已认证，之后所有客户端发来的包都按照命令格式解析。
下面这段Python伪代码展示了如何在转发过程中提取SQL命令：
def handle_client_to_server(client_sock, server_sock):
state = "AUTH"
while True:
packet = read_packet(client_sock)
if not packet:
break
if state == "AUTH":
# 认证阶段直接转发，不解析
server_sock.sendall(packet)
# 读取服务器响应并转发，判断认证是否成功
resp = read_packet(server_sock)
client_sock.sendall(resp)
if resp[4] == 0x00: # OK包
state = "READY"
elif state == "READY":
# 命令阶段，负载第一个字节是命令类型
command = packet[4]
if command == 0x03: # COM_QUERY
sql = packet[5:].decode('utf-8', errors='ignore')
print(f"捕获SQL: {sql}")
server_sock.sendall(packet)
上述代码简化了错误处理和EOF的判断。真实环境中还需要处理大数据包拆分、SSL加密连接等情况。如果代理要支持SSL，则必须解析握手包中的SSL请求标志，并在客户端和服务器之间建立各自的SSL会话，这会增加大量复杂度。对于学习用途，我们可以先只支持非SSL连接。
另外一个重要细节是代理不能随意改变数据包的到达顺序。MySQL协议对包的顺序有严格要求，比如查询命令后必须等待服务器的响应，响应可能包含多个包（列定义、行数据、EOF标记等）。代理只需要按原顺序转发，不能因为日志解析而延迟或重排。因此，提取SQL的操作应当是非阻塞的，不应影响主转发流程。
扩展思路与生产级注意事项
一旦掌握了基础的协议转发，就可以在这个代理上添加各种功能。例如，读写分离可以在识别出COM_QUERY命令后，判断SQL是SELECT还是UPDATE/INSERT，然后路由到不同的后端连接。连接池可以复用已经建立的后端连接，避免频繁握手。SQL防火墙则可以解析SQL语句，匹配危险操作并拒绝执行。
生产环境中的MySQL代理还需要考虑后端连接管理、心跳检测、超时处理、并发限制等。协议方面，要正确处理MySQL的认证插件（如caching_sha2_password）、压缩协议、LOAD DATA LOCAL INFILE的特殊数据流等。此外，当后端连接断开时，代理需要及时关闭客户端连接，避免资源泄漏。
一个常见的坑是代理只维护了一个全局的序列号计数器，而实际上每个TCP连接独立维护序列号。如果代理复用一个后端连接处理多个客户端会话，就必须为每个客户端会话单独维护序列号映射，否则协议解析会错乱。这也是为什么很多生产级代理会选择实现完整的协议栈，而不是简单的字节转发。
总之，从零实现一个MySQL代理中间件，最重要的收获不是代码本身，而是对数据库通信协议细节的深刻理解。当你能够清晰地画出握手、认证、命令、响应的完整时序图，并且知道每个数据包的边界和序列号如何变化时，再去使用或调试现有的中间件就会更加得心应手。