1. 项目概述为什么一个数据库进程的网络IO模型值得单独讲透你有没有遇到过这样的情况MySQL服务明明CPU和内存都空闲但客户端连接却频繁超时、查询响应慢得像卡在半路或者在压测时QPS上不去监控显示网络收发包速率始终上不去而网卡队列却堆满了等待处理的连接又或者在排查某个慢查询时发现它根本没进到SQL解析阶段就卡在“Waiting for source to become ready”这类状态里这些现象背后往往不是SQL写得差也不是索引没建好而是mysqld这个进程本身怎么跟网络打交道——也就是它的网络IO模型出了问题。“MySQL系列5mysqld之网络IO模型”这个标题表面看是讲一个底层技术点实则是一把打开MySQL高并发、低延迟能力天花板的钥匙。它不讲SQL语法不讲InnoDB锁机制而是直指MySQL作为服务端程序最基础、最核心的“呼吸系统”它如何同时听成百上千个客户端的请求又如何把结果高效地送回去。这决定了MySQL能承载多少连接、能撑住多大吞吐、在突发流量下是否稳定。对DBA来说这是调优的起点对后端工程师来说这是理解数据库瓶颈边界的必修课对SRE来说这是设计可观测性指标的关键依据。我做过好几个线上系统的数据库架构支撑从单机小站到日均亿级请求的中台服务。踩过的最深的坑之一就是早期只盯着innodb_buffer_pool_size和max_connections调参结果在一次促销活动前压力测试中QPS刚到8000就出现大量连接拒绝netstat -s | grep listen overflows显示监听队列溢出次数飙升。最后追根溯源发现是Linux内核的somaxconn值远低于MySQL配置的back_log而mysqld主线程在默认的阻塞式accept模型下根本来不及消费完SYN队列里的连接请求。这个教训让我彻底明白不懂mysqld的网络IO模型就像给一辆F1赛车只调发动机却不检查变速箱和轮胎——再强的内核也跑不起来。这篇内容就是把mysqld这个“黑盒”在网络层的运作逻辑一层层剥开给你看。它不依赖任何外部工具或中间件完全基于MySQL源码逻辑、Linux系统调用原理和真实压测数据。你会看到mysqld启动时到底创建了几个socket、绑定了哪些端口主线程和工作线程之间如何分工协作epoll/kqueue/select这些IO多路复用机制在MySQL里是怎么被调用的当连接数从100涨到10万时模型切换的临界点在哪里以及最关键的——你在my.cnf里改的每一个网络相关参数背后究竟触发了哪一段代码逻辑。这不是理论推演而是我把某跨平台系统数据库模块的调试日志、strace跟踪记录、perf火焰图全部拉出来一条条对照源码验证后的实操总结。2. mysqld网络IO模型的整体设计与思路拆解2.1 从单线程阻塞模型到现代异步模型的演进路径要真正理解mysqld现在的网络IO模型必须先看清它走过的路。MySQL 5.5及更早版本采用的是典型的单线程阻塞式模型Blocking I/O Model。整个mysqld进程只有一个主线程它的工作循环非常简单调用accept()系统调用阻塞等待一个新连接到来一旦有连接accept()返回一个新的socket文件描述符fd主线程立即在这个新fd上执行read()阻塞等待客户端发送完整的SQL请求收到请求后进行SQL解析、优化、执行、结果组装最后调用write()将结果发回客户端再次阻塞直到数据全部发出回到步骤1等待下一个连接。这个模型的优点是逻辑极其清晰代码简单调试方便。但致命缺陷在于无法并发。当主线程卡在第3步等客户端发SQL或第5步等网络把结果发出去时它完全无法响应其他任何连接请求。哪怕只是客户端网络抖动导致一个请求发了一半就卡住整个MySQL服务就“冻住”了。这显然无法满足现代互联网应用对高并发、低延迟的要求。于是从MySQL 5.6开始官方引入了线程池插件Thread Pool Plugin但这并非MySQL原生支持而是作为一个可选插件存在且在社区版中默认不启用。真正的转折点出现在MySQL 5.7。官方在源码层面重构了网络层引入了事件驱动线程池的混合模型Event-Driven Thread Pool Hybrid Model。这个模型的核心思想是让“等待”这件事不再由业务线程承担而是交给操作系统内核和专门的事件分发器来管理。它不再假设每个连接都需要一个专属线程而是把“连接建立”、“数据到达”、“数据可写”这些网络事件抽象出来由一个或多个事件循环Event Loop统一监听再将就绪的事件分发给工作线程池去处理。提示这里需要明确一个常见误区。很多人认为MySQL 5.7就是纯异步非阻塞模型Asynchronous Non-blocking I/O比如像Node.js那样。这是不准确的。MySQL目前采用的是同步非阻塞IOSynchronous Non-blocking I/O配合IO多路复用I/O Multiplexing。关键区别在于“异步”意味着发起一个IO操作如read后内核会负责把数据读到用户缓冲区并在完成后通知应用而MySQL的“同步非阻塞”是指应用自己调用read()如果数据没准备好read()会立刻返回错误EAGAIN/EWOULDBLOCK应用需要自己去轮询或等待事件就绪后再重试。MySQL选择后者是因为它需要对IO过程有极强的控制力比如精确控制每次读取的字节数、处理粘包/半包、实现自己的协议解析缓冲区而纯异步IO如Linux的io_uring在MySQL这种成熟、稳定、对兼容性要求极高的系统中引入成本和风险过高。2.2 MySQL 5.7的三层网络架构监听、事件、工作当前主流版本5.7, 8.0的mysqld网络IO模型可以清晰地划分为三个逻辑层每一层都有其明确的职责和对应的线程层级核心职责线程角色关键数据结构/机制对应源码模块监听层Listener Layer绑定端口、接受新连接请求、将新连接的socket fd注册到事件系统main thread(主线程)listen socket,back_log队列,accept()系统调用sql/mysqld.cc中的handle_connections_sockets()事件层Event Layer监听所有已注册socket fd上的网络事件可读、可写、错误并将就绪事件分发给工作层event_scheduler_thread(在--event-schedulerON时存在) 或由工作线程自身轮询epoll(Linux),kqueue(FreeBSD/macOS),select(Windows/旧系统),my_poll()封装vio/viosocket.c,mysys/my_poll.c工作层Worker Layer执行具体的SQL解析、执行、结果返回等业务逻辑从事件层获取就绪的socket fd进行read()/write()操作worker threads(由thread_cache_size和max_connections共同决定)THD(Thread Descriptor) 结构体,Vio(Virtual IO) 对象sql/sql_parse.cc,sql/sql_connect.cc这个三层架构的设计本质上是一种责任分离Separation of Concerns的工程实践。监听层只管“开门迎客”绝不碰SQL事件层只管“传话”绝不做决策工作层只管“干活”绝不关心连接从哪来。这种解耦带来了巨大的好处可伸缩性Scalability你可以独立地调整监听队列大小back_log、事件轮询频率、工作线程数量thread_cache_size而不会互相干扰。稳定性Stability即使某个工作线程因为一个复杂的SQL查询而长时间占用CPU监听层和事件层依然能正常工作新的连接请求不会被丢弃。可观测性Observability每一层都可以埋点监控。例如你可以监控Aborted_connects监听层失败、Threads_created工作层线程创建和Handler_read_rnd_next工作层执行效率从而精准定位瓶颈在哪个环节。我曾经在一个金融类后台系统中通过SHOW STATUS LIKE Threads_%命令发现Threads_created数值在高峰期每秒增长超过5个而Threads_cached几乎为0。这直接指向了工作层的线程创建/销毁过于频繁。结合perf top分析发现90%的CPU时间花在了pthread_create和pthread_join的系统调用上。最终解决方案不是增加max_connections而是将thread_cache_size从默认的0提升到16并配合应用层的连接池优化使Threads_created降到了每分钟个位数。这个案例完美印证了三层架构的价值问题被精准定位到“工作层”的线程生命周期管理上而不是笼统地归咎于“MySQL性能差”。2.3 模型选型背后的硬核考量为什么是epoll而不是libevent或自研在决定使用哪种IO多路复用机制时MySQL官方团队做了非常务实的选择。Linux平台下epoll是绝对的首选。原因并非因为它“最新潮”而是因为它在MySQL的特定负载场景下综合表现最优。首先对比select和poll。它们的共同缺陷是时间复杂度O(n)。每次调用内核都需要遍历整个fd集合检查每一个fd的状态。当MySQL管理着数万个连接时这个遍历开销会成为不可忽视的瓶颈。而epoll的时间复杂度是O(1)的就绪事件获取 O(1)的单个fd注册/注销。它通过内核维护一个红黑树来存储所有被监听的fd并用一个链表来存放就绪事件。epoll_wait()调用时内核只需检查这个就绪链表是否为空如果非空则直接将链表中的fd拷贝给用户空间。这使得epoll在连接数巨大时性能优势呈指数级放大。其次为什么不采用更高级的libevent或libev等第三方事件库答案是可控性与确定性。MySQL是一个需要7x24小时稳定运行的核心基础设施。引入第三方库意味着引入了额外的依赖、潜在的bug、以及与MySQL自身内存管理和错误处理机制的兼容性风险。libevent虽然强大但它有自己的事件循环、自己的内存分配器、自己的日志系统。当MySQL需要在某个特定时刻强制中断一个正在进行的IO操作或者需要精确控制一个socket的TCP选项如TCP_QUICKACK时绕过libevent的封装直接操作底层socket会变得异常困难。而MySQL选择直接封装epoll系统调用在mysys/my_poll.c中意味着它对每一次epoll_ctl()的调用、每一个epoll_event结构体的填充都拥有100%的掌控权。这种“裸金属”级别的控制是构建一个极致稳定、可预测的数据库服务的基石。最后为什么没有像某些新兴数据库那样直接拥抱io_uringio_uring确实是Linux下一代异步IO的未来它能将IO提交和完成完全异步化理论上能进一步降低延迟。但截至MySQL 8.0.33它仍未被官方采纳。核心原因在于生态成熟度与风险收益比。io_uring是一个相对较新的内核特性不同Linux发行版的内核版本支持度不一需要5.1内核才能获得完整功能。对于一个需要在CentOS 7内核3.10、Ubuntu 18.04内核4.15等长期支持LTS系统上稳定运行的软件来说过早依赖一个尚未被广泛验证的新特性其带来的运维复杂性和潜在稳定性风险远大于它所能提供的那一点点性能提升。MySQL的选择永远是“足够好”而非“最前沿”。3. 核心细节解析与实操要点3.1 监听层深度剖析back_log、max_connections与内核参数的三角关系监听层看似简单却是整个网络模型的第一道闸门也是最容易被误解和配置错误的地方。它的核心参数只有两个back_log和max_connections但它们与Linux内核的net.core.somaxconn参数构成了一个紧密耦合的“三角关系”。配置不当轻则导致连接拒绝重则引发雪崩。max_connections是MySQL层面的最大连接数限制它决定了mysqld最多能同时维护多少个活跃的THD对象。这是一个软限制当达到上限时新的连接请求会被MySQL主动拒绝并记录Aborted_connects状态变量。back_log则完全不同。它定义的是操作系统内核为该socket维护的“已完成三次握手、等待mysqld调用accept()来取走”的连接队列长度。这个队列是内核维护的不是MySQL自己维护的。当客户端发起connect()服务端完成三次握手后这个连接就会被放入这个back_log队列。只有当mysqld的主线程调用accept()时才会从这个队列里取出一个连接为其创建一个新的socket fd并开始后续的认证和通信流程。注意back_log的值永远不会超过内核参数net.core.somaxconn。这是Linux内核的一个硬性保护。如果你在my.cnf里把back_log设为1024但sysctl net.core.somaxconn的值是128那么mysqld实际生效的back_log就是128。这是很多DBA踩过的第一个坑。我们来模拟一个真实的压测场景。假设你的服务器net.core.somaxconn 128back_log 1024无效max_connections 1000。现在你用一个压测工具如sysbench瞬间发起2000个并发连接请求。前128个连接顺利完成三次握手进入内核的back_log队列。第129个到第2000个连接在三次握手的最后一个ACK包发送后会因为back_log队列已满被内核直接丢弃并向客户端返回RST包。客户端收到RST表现为Connection refused错误。mysqld主线程开始以某个速度取决于CPU和调度从back_log队列中accept()连接。假设它每秒能处理50个那么128个连接需要约2.5秒才能全部取完。在这2.5秒内后续的连接请求持续被拒绝。这就是所谓的“连接风暴”下的雪崩效应。因此正确的配置顺序应该是首先sudo sysctl -w net.core.somaxconn2048永久生效需写入/etc/sysctl.conf然后在my.cnf中设置back_log 2048最后根据你的业务峰值QPS和平均查询耗时估算出所需的max_connections。一个粗略公式是max_connections ≈ (峰值QPS × 平均查询耗时秒数) × 2。例如峰值QPS为5000平均查询耗时20ms0.02秒则5000 × 0.02 × 2 200。但考虑到连接池、长连接、管理连接等通常会在此基础上乘以一个安全系数如3-5倍最终设为1000。我在线上环境曾见过一个反面案例某电商系统在大促前DBA只修改了max_connections却忽略了back_log和somaxconn。结果大促开始后前端服务日志里充斥着Cant connect to MySQL server on xxx (111)而MySQL自身的Threads_connected状态却只有不到100。经过ss -lnt命令检查发现Recv-Q即back_log队列已经堆积到128的上限证实了问题根源。这个教训告诉我们网络IO模型的调优从来不是只改MySQL一个配置文件就能搞定的事它是一场MySQL与Linux内核的协同作战。3.2 事件层核心机制my_poll()函数的奥秘与epoll事件注册策略事件层的“心脏”是my_poll()函数它位于mysys/my_poll.c。这个函数是MySQL对底层IO多路复用系统调用的统一抽象接口。无论你用的是Linux的epoll、macOS的kqueue还是Windows的select上层代码如sql/mysqld.cc都只调用my_poll()由它内部根据编译时的宏定义HAVE_EPOLL,HAVE_KQUEUE来选择具体的实现。my_poll()的核心逻辑可以简化为以下三步准备事件集将所有需要监听的socket fd包括监听socket和已建立的客户端socket及其期望的事件POLLIN表示可读POLLOUT表示可写收集到一个数组中。发起系统调用调用epoll_wait()或其他对应函数传入这个事件集和一个超时时间timeout。返回就绪事件epoll_wait()返回后my_poll()将内核返回的就绪事件数组转换成MySQL内部定义的my_socket_events结构体数组并返回给上层。其中最关键的细节在于事件注册策略。MySQL并不是对所有socket都采用相同的事件监听模式。它采用了两种模式的混合监听socketListen Socket永远只注册EPOLLIN事件。因为监听socket的“可读”事件就意味着有新的连接请求SYN包到达需要调用accept()来处理。它永远不会产生EPOLLOUT事件。客户端socketClient Socket注册策略是动态的、按需的。当一个新连接被accept()成功后mysqld会为它创建一个Vio对象并向epoll注册EPOLLIN事件。此时它只关心“客户端有没有发来新的SQL请求”。当mysqld需要向客户端发送一个较大的结果集时它可能一次write()无法将所有数据发完返回值小于待发送字节数且errno为EAGAIN。这时mysqld会将这个socket的EPOLLOUT事件注册到epoll中并将未发送完的数据缓存到Vio对象的内部缓冲区里。一旦epoll_wait()返回该socket的EPOLLOUT事件就绪mysqld就知道网卡发送缓冲区有空闲了于是从自己的缓冲区里取出剩余数据继续write()。数据发送完毕后mysqld会立即将EPOLLOUT事件从epoll中注销避免不必要的事件唤醒。这种“按需注册、及时注销”的策略是保证事件循环高效运转的关键。它避免了epoll需要持续监听一个永远不会有EPOLLOUT事件的socket从而减少了内核需要维护的事件数量和epoll_wait()的扫描开销。我在调试一个慢查询时曾用strace -p mysqld_pid -e traceepoll_wait,epoll_ctl命令跟踪过my_poll()的行为。观察到一个有趣的现象在执行一个返回百万行数据的SELECT * FROM huge_table时epoll_ctl(EPOLL_CTL_ADD)调用会频繁出现每次都是为同一个客户端socket添加EPOLLOUT而在查询结束后epoll_ctl(EPOLL_CTL_DEL)会紧随其后将其删除。这直观地证明了上述动态注册策略的存在。这种细粒度的控制是libevent等通用库难以做到的因为它们通常会对一个socket的读写事件进行“全生命周期”管理。3.3 工作层线程模型thread_cache_size的黄金法则与THD生命周期管理工作层是MySQL业务逻辑的执行者其核心是THDThread Descriptor结构体。每一个THD对象都代表了一个与客户端的会话Session它包含了该会话的所有上下文信息当前的SQL语句、事务状态、临时表、用户权限、字符集、以及最重要的——一个指向Vio对象的指针用于网络IO。THD的生命周期管理直接决定了工作层的效率。其流程如下创建Create当主线程accept()到一个新连接并完成身份认证后会调用thd_prepare_connection()创建一个新的THD对象。复用Reuse如果thread_cache_size 0当一个客户端断开连接COM_QUIT时mysqld不会立即销毁这个THD而是将其放入一个线程缓存池Thread Cache中。当下一个新连接到来时mysqld会优先从缓存池中取出一个THD对象进行复用而不是创建一个新的。销毁Destroy当缓存池已满或者THD在缓存池中闲置时间过长由thread_cache_timeout控制MySQL 8.0.23或者MySQL进程关闭时THD才会被彻底销毁。thread_cache_size就是这个缓存池的大小。它的设置遵循一个经典的“黄金法则”它应该等于你的应用连接池的平均并发连接数。例如如果你的Java应用使用HikariCP最大连接数maximumPoolSize设为50那么thread_cache_size设为50就是一个非常合理的起点。为什么是这个值因为如果thread_cache_size太小比如设为0那么每次客户端连接断开THD就被销毁下次连接又得重新创建。THD的创建和销毁涉及大量的内存分配malloc/free、结构体初始化、线程本地存储TLS设置等操作开销巨大。反之如果thread_cache_size太大比如设为1000而你的应用实际并发只有50那么这950个空闲的THD对象会长期驻留在内存中白白消耗宝贵的RAM资源并且增加了内存碎片。我曾经在一个高并发API网关的后端数据库上将thread_cache_size从默认的0调整为64。在一次持续30分钟的压测中Threads_created状态变量从平均每秒创建12个线程下降到整个压测期间总共只创建了3个线程。这意味着99.9%的连接都成功复用了缓存中的THD。与此同时Threads_cached的峰值稳定在60-64之间证明缓存池被充分利用。这个改动带来的直接效果是数据库的CPU sys系统态时间占比从15%下降到了3%因为省去了海量的线程创建/销毁的系统调用开销。此外还有一个常被忽略的参数thread_handling。它有三个可选值one-thread-per-connection默认每个连接一个线程即上面描述的经典模型。no-threads完全禁用线程所有操作都在主线程中串行执行。仅用于极端调试或嵌入式场景生产环境绝对禁用。pool-of-threads启用官方线程池插件。它会创建一个固定大小的线程池由thread_pool_size控制所有客户端连接的请求都提交到这个池中执行。这个模型在连接数极高10000且查询普遍较短的场景下能显著降低线程上下文切换的开销。但在我们的实践中除非有明确的压测数据证明其收益否则不建议轻易开启因为线程池插件的调试和监控复杂度远高于默认模型。4. 实操过程与核心环节实现4.1 全流程跟踪从mysqld启动到第一个查询响应的12个关键步骤要真正吃透mysqld的网络IO模型最好的方法是跟着它的代码走一遍。下面我将带你从mysqld进程启动开始详细拆解它处理第一个客户端查询请求的完整流程精确到每一个关键的函数调用和系统调用。这个过程我称之为“12步追踪法”它是我调试MySQL网络问题时最常用的手段。步骤1main()入口与全局初始化mysqld进程启动后首先进入sql/mysqld.cc的main()函数。这里会进行全局变量初始化、信号处理设置、以及最重要的——初始化网络子系统。调用init_net_server_extension()它会为后续的监听socket准备必要的数据结构。步骤2创建监听socketmain()接着调用mysqld_main()其中关键一步是init_server_components()。在这里init_server_tcpip_sockets()被调用它执行socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)创建一个socket fd然后调用setsockopt()设置SO_REUSEADDR允许端口重用最后调用bind()将其绑定到0.0.0.0:3306。步骤3设置监听队列紧接着listen()系统调用被执行其第二个参数就是我们在my.cnf中配置的back_log值。此时内核为这个socket创建了一个长度为back_log的连接队列。步骤4进入主事件循环mysqld_main()的最后程序进入一个无限循环while (!abort_loop) { handle_connections_sockets(); }。handle_connections_sockets()就是整个网络IO模型的“大脑”。步骤5my_poll()等待事件handle_connections_sockets()的第一件事就是调用my_poll()。此时my_poll()内部会将监听socket的fd加入到epoll实例中并注册EPOLLIN事件。然后调用epoll_wait()进入阻塞等待状态直到有事件发生。步骤6新连接到达epoll_wait()返回当客户端执行mysql -h 127.0.0.1 -P 3306 -u root -p时TCP三次握手完成。内核将这个连接放入back_log队列并向epoll实例发送一个就绪事件。epoll_wait()立刻返回告诉my_poll()有一个fd就绪了。步骤7accept()获取新连接handle_connections_sockets()拿到就绪的fd即监听socket后立即调用accept()。accept()从back_log队列中取出一个连接返回一个新的socket fd例如fd12并创建一个Vio对象来包装它。步骤8创建THD并启动新线程handle_new_connection()被调用它为新的fd12创建一个THD对象。然后根据thread_handling的配置调用create_thread_to_handle_connection(thd)。在默认的one-thread-per-connection模式下这会调用pthread_create()创建一个全新的工作线程。步骤9工作线程执行认证新创建的工作线程其入口函数是handle_connection()。它首先调用login_connection(thd)与客户端进行MySQL协议握手交换能力标志、进行密码认证。这个过程涉及多次read()和write()系统调用所有IO都通过Vio对象完成。步骤10接收SQL请求认证成功后工作线程进入主循环do_command(thd)。它调用my_net_read()这是一个封装了read()的函数从Vio对象中读取客户端发来的COM_QUERY包。my_net_read()内部会检查socket是否处于非阻塞模式如果read()返回EAGAIN它会调用my_poll()再次等待EPOLLIN事件就绪。步骤11SQL解析与执行dispatch_command()被调用它根据COM_QUERY包的内容调用mysql_parse()进行SQL解析然后mysql_execute_command()执行。这一步完全在内存中进行不涉及网络IO。步骤12发送结果并等待下一轮执行完成后send_result_set_metadata()和send_data()等函数被调用将结果集的元数据和行数据通过Vio对象的write()方法发送给客户端。如果数据量小一次write()即可完成如果数据量大write()会返回EAGAIN此时工作线程会注册EPOLLOUT事件然后yield()让出CPU等待下一次epoll_wait()通知它继续发送。这个12步流程清晰地展示了监听层、事件层、工作层是如何无缝协作的。它不是一个静态的模型图而是一个动态的、实时的、由无数个系统调用和函数调用构成的生命体。理解了这个流程你就拥有了在生产环境中快速定位网络瓶颈的“源代码级”视角。4.2 关键参数实操配置与效果验证纸上得来终觉浅绝知此事要躬行。下面我将给出一套经过线上验证的、针对不同规模业务的my.cnf网络参数配置模板并附上每一步的验证方法和预期效果。模板1中小型企业应用日活10万QPS1000[mysqld] # 网络基础 port 3306 bind-address 0.0.0.0 skip-networking OFF # 连接与监听 max_connections 500 back_log 1024 # 线程与缓存 thread_cache_size 16 thread_handling one-thread-per-connection # 内核参数需在Linux系统中同步配置 # echo net.core.somaxconn 1024 /etc/sysctl.conf # echo net.ipv4.tcp_fin_timeout 30 /etc/sysctl.conf # sysctl -p验证方法与预期启动MySQL后执行ss -lnt | grep 3306确认Recv-Q列的值为1024。使用sysbench --threads200 --time60 oltp_read_write run进行压测。压测期间执行SHOW STATUS LIKE Threads_%;Threads_connected应稳定在150-200之间Threads_created应小于10表明线程缓存有效Threads_cached应稳定在10-16之间。模板2大型互联网平台日活1000万QPS5000[mysqld] # 网络基础 port 3306 bind-address 0.0.0.0 skip-networking OFF # 连接与监听大幅提升 max_connections 2000 back_log 4096 # 线程与缓存精细化调优 thread_cache_size 64 thread_handling one-thread-per-connection # 可选启用线程池插件 # plugin-load-add thread_pool.so # thread_pool_size 16 # 内核参数激进调优 # echo net.core.somaxconn 4096 /etc/sysctl.conf # echo net.core.netdev_max_backlog 5000 /etc/sysctl.conf # echo net.ipv4.tcp_tw_reuse 1 /etc/sysctl.conf # sysctl -p验证方法与预期启动后ss -lnt应显示Recv-Q为4096。使用sysbench --threads5000 --time300 oltp_point_select run进行长时间压测。监控/proc/mysqld_pid/status中的Threads:字段应稳定在60-80之间工作线程数而非飙升到数千。使用perf record -p mysqld_pid -e syscalls:sys_enter_accept,syscalls:sys_enter_epoll_wait -g -- sleep 60生成火焰图应看到epoll_wait的调用占比远高于accept证明事件驱动模型在高效工作。模板3极致性能调优DBA专用需充分测试[mysqld] # 网络基础启用IPv6双栈减少DNS解析 port 3306 bind-address :: # 监听IPv4和IPv6 skip-name-resolve ON # 强制跳过DNS反向解析 # 连接与监听极限值 max_connections 10000 back_log 8192 # 线程与缓存最大化复用 thread_cache_size 128 thread_handling pool-of-threads thread_pool_size 32 thread_pool_stall_limit 500 # 毫秒防止线程池饥饿 # TCP优化内核级 # echo net.ipv4.tcp_slow_start_after_idle 0 /etc/sysctl.conf # echo net.ipv4.tcp_no_metrics_save 1 /etc
