各位好，我是老张。

上个月帮一个做即时通讯的团队做性能诊断。业务不复杂，好友关系表的读写，单次查询不到5毫秒。压到800并发，P99直接飙到2秒。DBA把连接池从200调到500，又调到1000。没用，反而更慢了。CPU才40%，内存还剩一半，IO也没打满。瓶颈在哪？

问题出在一个常见误解上：**连接数和并发能力不是线性关系**。连接池调大了，数据库内部的锁争抢反而把性能吃掉了。根因埋在数据库的线程模型里。

这件事其实有规律可循。OLTP场景下，连接池大小一般不超过CPU核数的20倍，推荐用**CPU核数 × (1 + 等待时间/执行时间)**这个公式估算。超过拐点，context switch暴涨，性能反降。

今天从MySQL和KingbaseES（KES）的内核实现出发，聊聊三个绕不开的问题：

- One-Thread-Per-Connection模型到底卡在哪
- 连接数超过多少，性能开始掉
- 高并发OLTP场景，连接池该怎么规划

## 第一个卡点：One-Thread-Per-Connection的锁争抢

One-Thread-Per-Connection是业界最经典的连接模型。每个客户端连接分一个独立线程，线程绑连接，连接绑线程。MySQL沿用这套至今，KES也保留了它作为兼容模式。乍一看挺好，但高并发下就露馅了。

一个事务的执行链路：解析SQL → 优化器生成执行计划 → 访问Buffer Pool读数据页 → 加锁 → 写Undo Log → 写Redo Log → 提交。这条链路上，Buffer Pool和锁子系统是全局共享的。

连接少的时候争抢不明显。连接一上来，多个线程同时访问同一个Buffer Pool的Page Hash Table，同一个Lock Manager的哈希桶，线程间的cache line bouncing就跟着来了。

我翻过MySQL 8.0的源码。Buffer Pool的`buf_pool->mutex`保护free list和LRU链表，每个Page的`buf_block_t->mutex`保护单页状态。连接数上去之后，频繁的页换入换出让`buf_pool->mutex`的争抢越来越厉害。

不过这里KES做了一个关键优化：根据实测，线程栈默认压到512K，只有MySQL的一半。连接私有内存按需分配，用到才分配，不像MySQL一上来就把sort buffer、join buffer全分配好。这意味着同样的连接数，KES的线程切换开销和内存压力天然更低。

压测数据对比：

| 连接数 | MySQL TPS | KES TPS | MySQL context switch/s | KES context switch/s |
|--------|-----------|---------|----------------------|---------------------|
| 50 | 32,000 | 35,000 | 12,000 | 9,000 |
| 200 | 68,000 | 75,000 | 45,000 | 28,000 |
| 500 | 71,000 | 80,000 | 130,000 | 65,000 |
| 1000 | 52,000 | 63,000 | 280,000 | 110,000 |

> 测试环境：8核32G，NVMe SSD，MySQL 8.0 / KES最新稳定版，sysbench oltp_read_write。以上数据基于作者实测环境，具体数字因硬件和配置会有所不同，但性能趋势与官方测试结论一致。

MySQL从200到500连接，TPS才涨了4%，context switch从4.5万跳到13万。到1000连接，TPS反倒掉了23%，延迟翻了将近7倍。

KES在同一条件下好一些，但走势一样：连接数上来之后，context switch也在涨，性能同样在拐点之后往下走。这是One-Thread-Per-Connection模型的先天局限，不管谁家的数据库，走到这条路都得面对。经验上看，连接数超过CPU核数的20-30倍，性能就开始走下坡路了。

## 第二个卡点：线程模型的内存开销

每个连接线程要吃两块内存：

- 线程栈空间，默认1MB（MySQL `thread_stack`参数）
- 连接私有内存，包括排序缓冲区（`sort_buffer_size`）、join缓冲区（`join_buffer_size`）、读写缓冲区等

MySQL 8.0默认配置下，每个连接至少占2-3MB。1000个连接，光连接层就吃掉2-3G内存。加上Buffer Pool、InnoDB Log Buffer、数据字典缓存这些，内存很快就不够用了。

前面提到KES的线程栈和私有内存都比MySQL小，这在内存维度的效果更直观。1000个连接跑下来，KES的连接层内存显著低于MySQL，实测在相似配置下约为MySQL的60%左右。省出来的内存给Buffer Pool用，等于间接提高了缓存命中率。

## 第三个卡点：锁子系统的争抢

高并发OLTP，事务短但密集，每个事务都要过Lock Manager这一关。MySQL的行锁管理用的是一个全局Lock System。`lock_sys->mutex`保护锁表结构，行锁和间隙锁挂在哈希表上。事务提交释放锁时，要遍历锁链表、修改状态、唤醒等待线程。事务越密集，这个锁的争抢越厉害。特别是热点行更新的场景，多个事务同时锁同一行，排队等锁，只能串行提交。

KES在锁管理上做了深度优化，多核并行场景下锁争抢显著降低。实测下来，混合读写场景KES在500并发时的锁等待时间比MySQL少了30-50%。热点行更新场景下，优势更加明显。

## One-Thread-Per-Connection vs Thread Pool：架构选择

上面三个卡点，根子都在One-Thread-Per-Connection模型。连接一多，线程就多，线程一多，争抢就大。Thread Pool是一个替代思路：预先创建固定数量的工作线程，一般等于CPU核数或2倍核数，把连接的SQL请求放进队列，工作线程从队列里取任务。连接和线程解绑了，线程数量不会随连接数暴涨，context switch大幅减少，线程复用也改善了CPU缓存命中率。

MySQL企业版支持线程池，社区版没有。MariaDB加了这个功能。KES原生支持线程池模式，默认就是开启的。而且KES的线程池还做了一层优化：它把线程分成多个Group，每个Group有独立的任务队列和监听线程。新连接按哈希分配到不同Group，某个Group里的慢查询不会阻塞别的Group。这样一来就避免了单队列的"排队效应"。混合负载场景下，短事务加少量长查询，性能衰减比单队列方案小得多。

压测对比（同样500连接）：

| 方案 | TPS | P99延迟 | context switch/s |
|------|-----|---------|-----------------|
| MySQL One-Thread-Per-Connection | 71,000 | 12ms | 130,000 |
| MySQL Thread Pool（企业版） | 85,000 | 4.2ms | 32,000 |
| KES Thread Pool | 89,000 | 3.8ms | 28,000 |

> 测试环境同上，KES版本为最新稳定版。以上数据基于作者实测环境，具体数字因硬件和配置会有所不同，但性能趋势与官方测试结论一致。

KES在线程池模式下，500连接的性能接近MySQL 200连接的水平。context switch降了一个数量级。

## 连接池规划的工程方法论

底层原理搞清楚了，回到工程实践。连接池到底设多大？不是拍脑袋的事，我常用一个公式：

**OLTP场景：连接数 = CPU核数 × (1 + 等待时间/执行时间)**

举个例子。CPU 8核，平均SQL执行2ms，平均等IO 0.5ms。连接数 = 8 × (1 + 0.5/2) = 10个。

听起来很少？这是单个应用节点的连接数。后面3个应用节点，数据库总共就30个连接。

实际工程中我会再加点缓冲：

| 场景 | 推荐连接数公式 | 说明 |
|------|---------------|------|
| 纯OLTP，无锁争抢 | CPU核数 × 2~3 | 等待时间极短 |
| OLTP，有热点行 | CPU核数 × 1.5~2 | 锁争抢会消耗CPU |
| 混合OLTP+OLAP | CPU核数 × 2~4 | 长查询会占住连接 |
| 开启线程池 | 连接数可以放开，但工作线程=CPU核数 | 线程池模式下连接数不是瓶颈 |

连接池的上限，就是"刚好把CPU打满"的那个值。再往上加，多余的连接只是排队等锁，白白烧掉线程上下文切换的开销。

## 高并发场景的架构建议

对于要撑百万级并发的OLTP系统，我有几条建议。应用层，连接池设小，用短连接复用。连接池大小按上面的公式算，别超过CPU核数的3倍。多实例横向扩展比单实例加大连接池靠谱得多。数据库层，优先选带原生线程池能力的数据库。KES的线程池加分组调度，在高并发下能把性能衰减控制住。另外在信创项目里，KES的Oracle兼容性不错，存储过程和PL/SQL基本不用改，迁移成本省了不少。监控层，盯三个指标就够了：活跃连接数、锁等待线程数、context switch频率。活跃连接数超过CPU核数2倍就该报警。

---

连接池设计看着简单，背后牵着数据库内核的线程模型、锁机制、内存管理好几个子系统。连接数不是调参游戏，得从底层原理去理解。

最后把这些年踩过的坑汇总一下，各位对照看看有没有中招：

1. 连接池调大就以为能扛住更多并发。实际上过了拐点，多余的连接全在排队等锁，context switch反而把CPU吃光了。连接数不是越大越好，得找到那个"刚好打满CPU"的点。
2. 只看CPU利用率，不看context switch频率。有次CPU才40%就以为还有余量，结果context switch已经飙到28万/s，大把时间耗在线程切换上。这个指标比CPU利用率更早暴露问题。
3. 多实例部署时，每个实例的连接池独立算。3个应用节点各配200连接，数据库总共600连接，远超最优值。应该用"单实例连接数 = 总最优连接数 / 实例数"来倒推每个节点的上限。
4. 迁移后忘了重新调连接池参数。从MySQL切到KES（原生线程池模式）后，连接数不再是瓶颈，但线程池的工作线程数（worker_threads）反而成了新参数。不调的话，线程池的优势发挥不出来。

生产环境里连接池调到多大才合适？各位有没有踩过什么坑，评论区聊聊。

我是老张，下篇见。


上个月帮一个做即时通讯的团队做性能诊断。业务不复杂，好友关系表的读写，单次查询不到5毫秒。压到800并发，P99直接飙到2秒。DBA把连接池从200调到500，又调到1000。没用，反而更慢了。CPU才40%，内存还剩一半，IO也没打满。瓶颈在哪？

高并发OLTP下连接池设置：为什么连接数越多性能反而越差？

从MySQL和KES的源码出发，拆解数据库连接池连接数上限的三个根因，给出OLTP场景下连接池大小的计算公式与避坑清单

数据库

后端

架构设计

数据库连接池性能优化实战：揭秘MySQL与KES在高并发场景下的性能差异。分析One-Thread-Per-Connection模型瓶颈，探讨线程池优化方案，提供连接池计算公式（CPU核数×(1+等待时间/执行时间)）。实测数据对比显示KES在线程栈优化、锁管理等方面表现更优，适合高并发OLTP场景。

内存管理

MariaDB

MySQL

OLTP

腾讯云 IM，全球通信，1折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

高并发OLTP下连接池设置：为什么连接数越多性能反而越差？-腾讯云开发者社区-腾讯云

高并发OLTP下连接池设置：为什么连接数越多性能反而越差？

高并发OLTP下连接池设置：为什么连接数越多性能反而越差？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐