1. 为什么说 mysqld 的网络 IO 模型不是“默认就懂”的事？

很多人第一次在某高校数据库实验室跑通 MySQL 启动命令后，会下意识认为：“它监听 3306 端口、接受 TCP 连接、执行 SQL、返回结果——不就是个标准的 C/S 架构服务吗？IO 肯定是阻塞式 socket + 多线程呗。”
这种理解在单机压测、百并发、低延迟场景下确实“够用”，甚至能跑出漂亮 QPS。但一旦进入真实业务环境——比如某跨平台系统上线首周，连接数从 200 突增至 4800，慢查询陡增 3 倍，而SHOW PROCESSLIST里却看不到明显阻塞线程；又或者某图像处理 Demo 在高吞吐写入时，Threads_connected居高不下，Aborted_connects却悄然上涨——这时候再翻官方文档查thread_handling参数，往往已经晚了。

mysqld 的网络 IO 模型，从来不是“开箱即用”的黑盒，而是一套可配置、可感知、可诊断的运行时契约。它决定了：新连接如何被接纳、请求如何被分发、线程如何复用、超时如何触发、异常连接如何清理。这些决策不写在 SQL 里，不体现在EXPLAIN输出中，却直接决定着你部署的实例能否扛住流量脉冲、是否会在凌晨三点因连接耗尽而静默拒绝新请求、会不会因一个慢客户端拖垮整组连接池。

更关键的是，MySQL 官方从 5.5 到 8.0，对底层网络层做了三次实质性重构：5.5 引入thread_pool插件雏形，5.7 默认启用thread_cache_size动态调节逻辑，8.0.14 起彻底剥离libevent依赖，改用原生 epoll/kqueue 实现异步事件循环（仅限 Linux/macOS）。这意味着——同一份配置文件，在不同版本上启动的 IO 行为可能截然不同。你看到的max_connections=2000，背后可能是 2000 个独占线程，也可能是 16 个线程轮询处理 2000 个活跃 socket。

我试过在某公司生产环境将 5.7 升级至 8.0.28 后，未调整任何网络参数，结果发现Threads_created每秒飙升至 120+，监控曲线像心电图一样剧烈抖动。排查三天才发现：8.0 默认关闭了thread_cache_size的自动伸缩机制，而旧版依赖的pthread_atfork回调在新线程模型下失效。这不是 bug，是模型演进带来的行为偏移。

所以，谈 mysqld 的网络 IO，不能只说“它用 epoll”，而要问：epoll_wait() 被谁调用？调用频率受什么控制？socket 的读写缓冲区由谁管理？连接空闲超时是内核 TCP keepalive 还是 mysqld 自己的 timer？这些问题的答案，散落在my.cnf的十几个参数、performance_schema的三张表、strace -e trace=epoll_wait,accept4,read,write的输出日志，以及mysqld启动时加载的sql/mysqld.cc和vio/viosocket.cc源码逻辑里。

这篇文章不讲抽象理论，也不堆砌源码行号。我会带你从一次真实连接建立开始，逐帧拆解数据包如何穿过内核协议栈、落入 mysqld 的事件队列、被哪个线程取出解析、执行完后响应如何写出——每一步都对应一个可验证、可调优、可监控的具体参数或行为。你不需要编译 MySQL，但读完后，应该能对着netstat -tnp | grep :3306的输出，准确说出每个ESTABLISHED状态连接背后，mysqld 正在做什么。

2. 连接建立阶段：accept() 调用者是谁？它真的“立即返回”吗？

当客户端执行mysql -h 127.0.0.1 -P 3306 -u root -p，TCP 三次握手完成后，内核已将该连接放入监听 socket 的已完成连接队列（accept queue）。此时，mysqld 必须调用accept()系统调用将其取出，才能开始认证与会话初始化。但这个accept()是谁在调用？频率如何？阻塞还是非阻塞？这是整个网络模型的起点。

2.1 两种主线程模型：one-thread-per-connection vs thread-pool

MySQL 提供两种根本不同的连接接纳策略，由thread_handling参数控制（注意：该参数不可动态修改，必须重启生效）：

提示：thread_handling=pool-of-threads并非所有版本都内置。5.5/5.6 需安装 Oracle 官方thread_pool插件；5.7+ 内置但默认禁用；8.0.14+ 已移除该模式，改用更轻量的native thread pool（基于std::thread+epoll），此时thread_handling参数被忽略，实际行为由thread_pool_size和thread_pool_stall_limit共同决定。

我们以最常用的one-thread-per-connection模式切入。主线程（通常 PID 与 mysqld 进程一致）在handle_connections_sockets()函数中执行核心循环：

while (!abort_loop) { // 1. 调用 accept4()（Linux）或 accept()（其他平台） // flags 参数含 SOCK_CLOEXEC，避免子线程继承 fd int client_sock = accept4(vio->sd, (struct sockaddr *)&cAddr, &len, SOCK_CLOEXEC); if (client_sock < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 无新连接，继续下一轮 epoll_wait 或 sleep continue; } else if (errno == EMFILE || errno == ENFILE) { // 文件描述符耗尽！此时 mysqld 不再 accept，但监听 socket 仍存活 log_error("Too many open files, stopping accept"); break; } } // 2. 创建新线程处理 client_sock create_new_thread(client_sock, &cAddr); }

关键点在于：accept()调用本身是阻塞的，但 mysqld 通过将监听 socket 设为非阻塞（non-blocking）+epoll事件驱动，实现了“伪非阻塞”效果。具体流程如下：

1. mysqld 启动时，调用set_nonblocking(vio->sd)将监听 socket 设为非阻塞；
2. 主线程不再直接accept()，而是将vio->sd注册到epoll实例，监听EPOLLIN事件；
3. 主线程进入epoll_wait(epoll_fd, events, max_events, timeout_ms)循环；
4. 当有新连接到达，epoll_wait返回，主线程再调用accept4()—— 此时因 socket 非阻塞，accept4()必然立即返回（成功或EAGAIN）；
5. 若返回EAGAIN，说明队列已空，继续下一轮epoll_wait。

这就是为什么你在strace -p $(pgrep mysqld) -e trace=accept4,epoll_wait中，会看到大量epoll_wait(...)调用，偶尔穿插一次accept4(...)成功返回。epoll_wait的timeout_ms值，由--connect-timeout（默认 10 秒）和内部调度逻辑共同影响，但并非简单等于该参数。

2.2 监听队列长度：back_log参数的真实作用域

back_log参数常被误解为“最大等待连接数”。实际上，它控制的是内核层面的已完成连接队列（accept queue）长度上限，而非 mysqld 应用层的待处理连接池。

Linux 内核中，每个监听 socket 有两个队列：

• SYN queue（半连接队列）：存放完成 SYN+SYN/ACK 但未收到 ACK 的连接，长度由net.ipv4.tcp_max_syn_backlog控制；
• Accept queue（全连接队列）：存放三次握手完成、等待accept()取出的连接，长度 =min(back_log, /proc/sys/net/core/somaxconn)。

假设你设置back_log=2048，但系统somaxconn=128，则实际队列长度仅为 128。当队列满时，内核会丢弃新到达的 ACK 包，客户端表现为Connection refused或超时重试。

我踩过的坑：某次压测中，ss -lnt显示Recv-Q持续为 128（即队列已满），但Threads_connected仅 800。排查发现somaxconn未调优，导致大量连接在内核层就被丢弃，Aborted_connects指标缓慢上涨，而 mysqld 日志毫无记录。解决方法很简单：echo 2048 > /proc/sys/net/core/somaxconn并写入/etc/sysctl.conf。

注意：back_log值需在 mysqld 启动前设置，且必须 ≤somaxconn。若back_log>somaxconn，mysqld 启动时会打印警告[Warning] Changed limits: max_open_files: 5000 (requested 65535)，但不会报错退出。

2.3 连接接纳的实时性瓶颈：thread_cache_size如何缓解线程创建压力

即使accept()调用本身很快，pthread_create()创建线程仍是昂贵操作（平均 100~300μs）。当每秒新建连接达数百时，主线程会陷入高频accept()→pthread_create()循环，CPU 花费在上下文切换而非 SQL 执行上。

thread_cache_size就是为此而生：它定义了一个“空闲线程缓存池”。当某个客户端连接断开时，mysqld 不立即销毁其对应线程，而是将其放入缓存池。下次新连接到来，优先从缓存中取线程复用，避免pthread_create()开销。

其工作逻辑如下：

• 缓存池大小上限 =thread_cache_size；
• 当前缓存中空闲线程数 <thread_cache_size，且有连接断开，则线程入缓存；
• 当前缓存中空闲线程数 > 0，且有新连接到来，则从缓存取线程，不创建新线程；
• 缓存中的线程若空闲超时（默认 15 秒，由thread_cache_timeout控制），则被销毁。

实测数据：在某电商订单库（5.7.32），thread_cache_size=16时，Threads_created稳定在 0.2/s；设为 0 后，峰值达 80/s。但thread_cache_size并非越大越好——每个缓存线程占用约 256KB 栈空间，100 个缓存线程即消耗 25MB 内存，且可能掩盖连接泄漏问题（本该销毁的线程被缓存，Threads_connected居高不下）。

判断是否需要调优：观察Threads_created / Threads_connected比值。若 > 0.1，说明线程创建频繁，应增大thread_cache_size；若长期为 0 且Threads_connected波动小，可设为 0 以节省内存。

3. 连接生命周期内：一个 SQL 请求如何被 IO 层流转？

连接建立后，客户端发送0x01 0x00 0x00 0x00 0x03 SELECT ...这样的二进制协议包。这个字节流如何从网卡进入 mysqld 内存、被解析、执行、再将结果写出？这中间的 IO 路径，才是网络模型的核心战场。

3.1 VIO 层：MySQL 的统一 IO 抽象接口

MySQL 将所有网络通信（TCP、Unix Socket、SSL）和本地文件 IO，统一抽象为VIO（Virtual IO）结构体。每个客户端连接对应一个VIO* vio对象，封装了：

• sd：socket 描述符（int 类型）；
• read_timeout,write_timeout：读写超时（毫秒）；
• retry_count：重试次数；
• read_function,write_function：函数指针，指向具体实现（如vio_read_socket,vio_write_socket）。

VIO 层的关键设计是：所有读写操作均以“尝试一次 + 检查返回值”方式实现，不隐藏EAGAIN/EWOULDBLOCK。例如vio_read_socket()：

ssize_t vio_read_socket(Vio *vio, uchar *buf, size_t size) { ssize_t ret; do { ret = recv(vio->sd, buf, size, MSG_WAITALL); // Linux 下等价于 read() } while (ret == -1 && (errno == EINTR)); // 仅重试被信号中断的情况 if (ret == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 非阻塞 socket 无数据可读，返回 0（表示“暂无数据”，非错误） return 0; } // 其他错误（如 ECONNRESET）才返回 -1 } return ret; }

这意味着：上层协议解析代码（如do_command()）必须主动处理vio_read_socket()返回 0 的情况——它不代表连接关闭，只代表当前 socket 接收缓冲区为空，需等待下一次epoll_wait通知可读事件。

3.2 事件驱动循环：poll()与epoll()的实际分工

mysqld 的事件循环并非全程使用epoll。它采用分层策略：

重点来了：epoll_wait()的timeout_ms值，并非固定不变。mysqld 会根据当前负载动态调整：

• 若epoll_wait()返回 0 次事件（即超时），说明无新连接、无新数据、无超时事件，此时timeout_ms会指数退避（如 1ms → 2ms → 4ms...），降低 CPU 占用；
• 若连续多次返回事件，timeout_ms会缩短（如 100ms → 50ms → 10ms），提升响应灵敏度。

这个逻辑在vio/viosocket.cc的vio_poll_read()函数中实现。你可以通过perf record -e syscalls:sys_enter_epoll_wait -p $(pgrep mysqld)抓取epoll_wait调用，再用perf script查看timeout_ms参数变化，验证此行为。

3.3 协议解析与缓冲区管理：net_buffer_length与max_allowed_packet

当epoll_wait通知某 socket 可读，mysqld 调用my_net_read()从该 socket 读取数据。但这里有个关键细节：它不会一次性读完所有可用字节，而是按需分块读取。

my_net_read()的核心逻辑：

1. 检查net->buff（网络缓冲区）中是否有残留未解析数据（来自上次读取）；
2. 若无，调用vio_read()尝试读取min(net->remain_in_buf, net->max_packet)字节；
3. 若vio_read()返回 0（EAGAIN），则等待下一次epoll_wait；
4. 若返回 >0，将数据拷贝到net->buff，更新net->buff_ptr和net->buff_end；
5. 解析net->buff中的完整协议包（MySQL Packet Header 为 4 字节：len_low, len_mid, len_high, seq_id）；
6. 若net->buff中数据不足一个完整包头（4 字节），返回0，等待下次读取；
7. 若包头指示包长len>net->max_packet，则报错Packet too large。

其中net->max_packet由max_allowed_packet参数控制（默认 4MB），而net->buff的初始大小由net_buffer_length控制（默认 16KB）。这意味着：

• 如果客户端发送一个 2MB 的LOAD DATA INFILE包，my_net_read()会先读 16KB 到缓冲区，发现不够，再读下一批，直到凑够 2MB；
• 若net_buffer_length过小（如 1KB），会导致频繁vio_read()调用和内存拷贝，增加延迟；
• 若max_allowed_packet过小，大结果集会被截断，客户端收到MySQL server has gone away错误。

实操建议：对于以大 BLOB 读写为主的场景，将net_buffer_length设为max_allowed_packet的 1/4（如max_allowed_packet=64M，则net_buffer_length=16M），可减少 75% 的vio_read()调用次数。

3.4 写响应的零拷贝优化：sendfile()与writev()的抉择

当 SQL 执行完毕，mysqld 需将结果包（如0x07 0x00 0x00 01 0x00 0x00 0x00 0x02 ...）写出 socket。这里有两个关键路径：

• 普通写入（write()）：将结果数据从 mysqld 内存拷贝到内核 socket 发送缓冲区；
• 零拷贝写入（sendfile()）：若结果来自磁盘文件（如SELECT LOAD_FILE('/tmp/data.txt')），mysqld 可调用sendfile()，让内核直接从文件页缓存 DMA 到 socket，避免用户态内存拷贝。

但sendfile()有严格限制：仅支持文件 → socket，且文件需在本地文件系统。因此，95% 的 SQL 响应仍走write()路径。

更高效的替代是writev()：它允许将多个内存块（如包头、包体、尾部校验）一次性提交给内核，避免多次write()系统调用开销。mysqld 在net_real_write()中正是这样做的：

struct iovec iov[3]; iov[0].iov_base = packet_header; // 4字节头 iov[0].iov_len = 4; iov[1].iov_base = packet_body; // 实际数据 iov[1].iov_len = body_len; iov[2].iov_base = packet_footer; // 可选校验 iov[2].iov_len = footer_len; ssize_t ret = writev(net->vio->sd, iov, 3);

writev()的优势在于：一次系统调用完成多段数据写出，内核可将其合并为一个 TCP segment（若开启TCP_NODELAY），显著降低小包数量。这也是为什么在高 QPS 场景下，开启skip_name_resolve（避免 DNS 查询阻塞）和innodb_flush_log_at_trx_commit=2（降低刷盘频率）后，writev()调用次数与 QPS 基本呈线性关系——它是 IO 路径上最可控的性能杠杆之一。

4. 超时与异常处理：连接为何“静默死亡”？wait_timeout不是你想的那样

很多 DBA 遇到过这种现象：应用端显示连接正常，但执行 SQL 时卡住数分钟，最终报错Lost connection to MySQL server during query；或者SHOW PROCESSLIST里一堆Sleep状态连接，Time列显示 3600+ 秒，却迟迟不被释放。这背后，是 mysqld 对连接生命周期的精细化管控，而wait_timeout只是冰山一角。

4.1 三层超时体系：网络层、协议层、会话层

mysqld 的连接超时不是单一参数，而是三层嵌套机制：

三者关系是：网络层超时是最后兜底，协议层超时是主动清理，会话层超时是防止单语句霸占资源。它们互不干扰，各自独立计时。

• interactive_timeout：仅对mysql_real_connect()时设置了CLIENT_INTERACTIVE标志的连接生效（如 mysql CLI 客户端）；
• wait_timeout：对所有其他连接生效（如 JDBC、PHP mysqli）；
• 两者均从最后一次成功接收客户端数据的时间点开始计时，而非连接建立时间。

关键误区：很多人以为wait_timeout=60就能让空闲连接 60 秒后自动断开。但实际中，若客户端开启了 TCP keepalive（如 Java 的socket.setKeepAlive(true)），内核会定期发送探测包，只要探测成功，wait_timeout计时器就不会归零。只有当 mysqld 在wait_timeout时间内既未收到任何数据，也未收到 TCP keepalive 探测响应时，才会关闭连接。

4.2Aborted_connects与Aborted_clients：两个指标的血泪区别

这两个指标常被混为一谈，但它们的成因和诊断价值天差地别：

我处理过一个典型案例：某微服务集群Aborted_clients每小时增长 200+，但Aborted_connects为 0。抓包发现，客户端在发送COM_QUERY后，未等待响应就直接发送FIN包关闭连接。根源是应用层设置了socket.setSoTimeout(5000)，但 SQL 执行因锁等待超时，客户端超时后强制断连。解决方案不是调大wait_timeout，而是优化 SQL 或增加应用层重试逻辑。

4.3 连接泄漏的终极诊断法：performance_schema三表联动

当Threads_connected持续攀升，Aborted_clients却不高，极可能是应用未正确关闭连接。此时SHOW PROCESSLIST只能看到当前快照，无法追溯连接来源。performance_schema提供了黄金组合：

1. performance_schema.threads：记录每个线程的PROCESSLIST_ID,TYPE,NAME,PROCESSLIST_INFO（当前执行语句）；
2. performance_schema.events_statements_current：记录每个线程最近一条执行的语句及耗时；
3. performance_schema.socket_summary_by_instance：按 socket 实例统计读写字节数、等待时间。

实战查询（定位长时间空闲连接）：

SELECT t.PROCESSLIST_ID as conn_id, t.PROCESSLIST_USER as user, t.PROCESSLIST_HOST as host, t.PROCESSLIST_DB as db, t.PROCESSLIST_COMMAND as cmd, t.PROCESSLIST_TIME as idle_sec, s.SUM_TIMER_WAIT/1000000000 as total_wait_sec, s.COUNT_READ as read_cnt, s.SUM_NUMBER_OF_BYTES_READ as read_bytes FROM performance_schema.threads t JOIN performance_schema.socket_summary_by_instance s ON t.THREAD_ID = s.THREAD_ID WHERE t.TYPE = 'FOREGROUND' AND t.PROCESSLIST_COMMAND = 'Sleep' AND t.PROCESSLIST_TIME > 300 -- 空闲超5分钟 ORDER BY t.PROCESSLIST_TIME DESC LIMIT 10;

该查询能精准定位到：是哪个用户、从哪台主机、连接到哪个库、空闲多久、期间读取了多少字节。结合应用日志，可快速锁定泄漏源头——比如某 Python Flask 应用在异常分支中忘记调用conn.close()。

注意：启用performance_schema有约 5% 性能开销，但socket_summary_by_instance表默认关闭。需在启动时设置performance_schema_consumer_events_statements_current=ON和performance_schema_consumer_socket_instances=ON。

5. 生产环境调优 checklist：从参数到监控的闭环实践

纸上得来终觉浅。以下是我过去三年在多个 MySQL 生产环境落地的调优 checklist，覆盖参数配置、OS 内核、监控告警三个维度，每项均附带验证方法和风险提示。

5.1 MySQL 参数层：10 个必检参数及其安全阈值

提示：所有参数修改后，必须执行SELECT @@variable_name;确认生效。部分参数（如max_connections）需重启，可通过mysqladmin shutdown+mysqld_safe &安全重启。

5.2 OS 内核层：4 个必须调优的 sysctl 参数

MySQL 是重度依赖内核网络栈的服务，以下参数直接影响连接接纳能力和稳定性：

永久生效方法：将配置写入/etc/sysctl.conf，执行sysctl -p加载。切勿在生产环境临时修改后忘记持久化。

5.3 监控告警层：5 个核心指标与阈值公式

脱离监控的调优都是空中楼阁。以下是我在 Grafana 中配置的 5 个黄金指标，全部基于information_schema和performance_schema：