MySQL 网络通信浅析

MySQL的网络通信协议主要包含以下几个层次,从最上层的MySQL数据包协议层到最底层的socket传输:

  1. | THD
  2. | Protocol
  3. | NET
  4. | VIO
  5. | SOCKET

本文主要扫一下相关的代码,以下分析基于MySQL5.7。

创建会话

在MySQL5.7中对会话协议层的代码进行了大量的重构以优化性能,并使得代码更加可读。以下这幅图大概展示了几个相关的类关系(未包含诸如windows平台的相关类)

mysql-connect

创建用户线程堆栈是从主线程开始的,监听客户端请求并创建处理线程

  1. mysqld_main
  2. |-->connection_event_loop
  3. |-->listen_for_connection_event
  4. //根据不同的监听模式,去监听新请求, 当获取到一个新的监听请求时,会创建一个Channel_info类,用 来存储用户的socket信息
  5. |-->Connection_handler_manager::process_new_connection
  6. |-->Per_thread_connection_handler::add_connection
  7. //我们通常用的one thread one connection对应的类为Per_thread_connection_handler
  8. |-->创建用户线程,线程函数为handle_connection

在MySQL5.7里一个重大的优化,如上所述,就是关于用户会话的thd, net, vio等信息的初始化都不是在主线程进行的,而是创建用户线程后,由用户线程自己来完成。通过这种方式,主线程可以更高效的接受新的连接请求,从而优化了在短连接场景下的性能。见官方博客 及相应的worklog

下面这幅图摘自官方博客,大家感受下5.7相比之前版本的短连接性能优化:

perf-short-connection

创建用户会话的主要函数栈包括:

  1. handle_connection //线程入口函数
  2. |-->init_new_thd
  3. |-->Channel_info_local_socket::create_thd
  4. |-->Channel_info::create_thd
  5. |-->create_and_init_vio
  6. |-->Protocol_classic::init_net
  7. |-->my_net_init
  8. |-->vio_fastsend //设置socket选项
  9. * 设置IP_TOSIPTOS_THROUGHPUT
  10. * 设置TCP_NODELAY
  11. |-->Global_THD_manager::add_thd
  12. // 加入到thd链表上
  13. |-->thd_prepare_connection
  14. |-->login_connection
  15. |--> check_connection
  16. //检查链接,设置thd的链接信息,
  17. |--> vio_keepalive // 设置SO_KEEPALIVE选项
  18. |--> acl_authenticate // 权限认证
  19. |-->prepare_new_connection_state
  20. //如果连接打开了CLIENT_COMPRESS,设置NET::compress为true。
  21. //如果设置了init_connect,则在这里执行对应的SQL语句
  22. /* 循环接受请求并处理(do_command) */
  23. |-->Protocol_classic::get_command
  24. |-->Protocol_classic::read_packet
  25. |-->my_net_read // 读取command包,这里的读超时时间由wait_timeout决定
  26. |-->close_connection
  27. |-->THD::disconnect
  28. |-->THD::shutdown_active_vio
  29. |-->vio_shutdown /* 关闭socket */

NET/VIO

my_net_write

该函数用于将数据拷贝到NET缓冲区,当长度大于MAX_PACKET_LENGTH(即4MB-1字节)会对Packet进行拆分成多个packet。每个Packet的头部都会留4个字节,其中:1~3字节,存储该packet的长度,第4个字节存储当前的packet的序号,每存储一次后递增net->pkt_nr

每个Net对象有一个Buff(net->buff),即将发送的数据被拷贝到这个buffer中,当Buffer满时需要立刻发出到客户端。如果Buffer足够大,则只做memcpy操作。net->write_pos被更新到写入结束的位置偏移量 (net_write_buff)

如果一次写入的数据被拆分成多个Packet,那么net->pkt_nr也对应的递增多次. pkt_nr的作用是在客户端解析时,防止包发送乱序。

net_flush

实际上在my_net_write函数中,如果net->buff不够用,已经会做网络写了,net_flush最终保证所有在buff中的数据被写到网络

当客户端启用压缩协议时,这里会有些不同的,会给packet头部再加3个字节(COMP_HEADER_SIZE),被压缩的数据不包含头部的7个字节:

  1. [3bytes:Packet的长度]
  2. [1bytes: pkt_nr]
  3. [3bytes:压缩后的长度]
  4. [1bytes: compress_pkt_nr]

同样的,每个压缩包都会递增net->compress_pkt_nr

net_write_raw_loop

当packet准备好发送后,调用函数net_write_raw_loop开始进行数据发送

  • 发送模式受vio->write_timeout影响(通过参数net_write_timeout控制);当该参数被设置成大于等于0时,使用非阻塞模式send数据包(MSG_DONTWAIT)
  • 若网络发送被中断(EINTR),会去尝试重传
  • 使用非阻塞模式send,每次并不保证数据全部发送完毕,因此需要循环的调用直到所有的数据都发送完毕
  • 当输出缓冲区满时,获得错误码EWOULDBLOCK/EAGAIN,则阻塞等待(vio_socket_io_wait),最大等待时间为net_write_timeout,超时则返回错误

my_net_read

根据NET接口先读取数据包(net_read_packet):

  • 先读取packet header,一个普通的packet header包含4个字节,压缩协议下则另外再加3个字节,如上述(net_read_packet_header)。其中的pkt_nr会提取出来和本地的值相比较。在读写两段维持的pkt_nr自增值保证了服务器和客户端的通信以一种有序的方式进行,并用于校验包的有序性。如果不一致,则说明网络包发生了乱序。直接报错。如果一致,本地net->pkt_nr++
  • 从packet header中提取剩下的packet长度,继续从socket读取

Vio

Vio在NET的更下一层,封装了所有对socket的操作。根据不同的连接类型(TCP/IP, Socket, Name Pipe, SSL, SHARED MEMORY),相关函数指针在vio_init函数中定义,这里不展开描述

相关参数

  • connect_timeout: 在连接认证阶段的网络交互超时时间(ref login_connection);
  • wait_timeout: 等待来自客户端的新的command请求;
  • net_read_timeout: 一般情况下的SQL通常直接从command发过来,但拿到command后,在一条语句内可能还需要和客户端交互,这里会用到该timeout值,例如load data local infile语句;
  • net_write_timeout: 就是通过网络发送数据的最大超时时间;
  • interactive_timeout: 当客户端打开选项CLIENT_INTERACTIVE时,将当前会话的NET的wait_timeout设置为该值;

结果集

MySQL有两种常用的数据协议,一种是用于Prepared Statement,对应类为Protocol_binary,另外一种是普通的协议,对应类为Protocol_classic

我们以一个简单的表为例:

  1. mysql> create table t1 (a int, b int);
  2. Query OK, 0 rows affected (0.00 sec)
  3. mysql> insert into t1 values (1,1),(2,2);
  4. Query OK, 2 rows affected (0.00 sec)

当执行最后一条select操作时,这里使用的类为Protocol_classic

发送metadata

  • ref: Protocol_classic::start_result_metadata

将列的个数写入Net缓冲区

  • ref: Protocol_classic::send_field_metadata

逐列的准备元数据信息,包含:

  1. | 3bytes 标识符:def
  2. | db_name
  3. | table_name
  4. | org_table_name
  5. | col_name
  6. | org_col_name
  7. | 字符集编码
  8. | 列长度
  9. | 列类型
  10. | flags
  11. | decimals(这里为0)
  12. | 预留
  13. | 预留

可以看到每个列的元数据都包含了非常多的信息,使用字符串存储,这也意味着对于一条简单的SQL,你的网络传输的内容可能大多数都是元数据,即时你的客户端可能并不需要引用到。

有多个列就写多个packet到Net buffer (Protocol_classic::end_row)

  • ref: Protocol_classic::end_result_metadata

write_eof_packet函数会被调用,用于标识元数据信息到此结束。此处共写5个字节(不含packet header)

发送数据

ref: end_send --> Protocol_classic::end_row

如上例,发送两行数据的packet包括

1‘1’1‘1’
1‘2’1‘2’

结束发送

ref: THD::send_statement_status -->net_send_eof --> write_eof_packet

发送结果结束标记,其中包含了sql执行过程中产生的warning个数

元数据开销

从上述可以看到,结果集中有很大一部分的开销是给元数据的,这意味着类似普通的pk查询,元数据的开销可能会非常昂贵。

以下贴下我之前测试过的一个例子,增加了几个选项来控制发送的元数据量:

  1. 0/METADATA_FULL: return all metadata, default value.
  2. 1/METADATA_REAL_COLUMN: only column name;
  3. 2/METADATA_FAKE_COLUMN: fake column name ,use 1,2...N instead of real column name
  4. 3/METADATA_NULL_COLUMN: use NULL to express the metadata information
  5. 4/METADATA_IGNORE: ignore metadata information, just for test..

测试表:

  1. CREATE TABLE `test_meta_impact` (
  2. `abcdefg1` int(11) NOT NULL AUTO_INCREMENT,
  3. `abcdefg2` int(11) DEFAULT NULL,
  4. `abcdefg3` int(11) DEFAULT NULL,
  5. `abcdefg4` int(11) DEFAULT NULL,
  6. ……
  7. ……
  8. `abcdefg40` int(11) DEFAULT NULL,
  9. PRIMARY KEY (`abcdefg1`)
  10. ) ENGINE=InnoDB AUTO_INCREMENT=229361 DEFAULT CHARSET=utf8

使用mysqlslap测试并发pk查询

  1. mysqlslap --no-defaults -uxx --create-schema=test -h$host -P $port --number-of-queries=1000000000 --concurrency=100 --query='SELECT * FROM test.test_meta_impact where abcdefg1 = 2'

测试结果

  1. METADATA_FULL : 3.48w TPS, Net send 113M
  2. METADATA_REAL_COLUMN: 7.2W TPS, Net send 111M
  3. METADATA_FAKE_COLUMN: 9.2W TPS , Net send 116M
  4. METADATA_NULL_COLUMN: 9.6w TPS , Net send 115M
  5. METADATA_IGNORE: 13.8w TPS, Net send 30M

很显然无论网络流量还是TPS吞吐量,在这个人为构造的极端场景下,元数据的开销都非常的显著。