这两天一直在研究这个话题，踩了几个坑，把遇到的东西整理成文，供有需要的朋友参考。
**
🎬 个人主页：艾莉丝努力练剑
❄专栏传送门：《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》
《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》
⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平
🎬 艾莉丝的简介：
文章目录
- 1 ~> MySQL 连接池原理与实现
- 1.1 连接池产生背景：短连接的性能瓶颈
- 1.2 连接池核心设计思想
- 1.3 线程绑定式连接池实现模型
- 1.3.1 核心组件
- 1.3.2 任务执行与回调机制
- 1.3.3 连接保活与故障恢复
- 1.3.4 单连接基础 API 示例
1 ~> MySQL 连接池原理与实现
1.1 连接池产生背景：短连接的性能瓶颈
传统数据库短连接模式下，每次执行 SQL 都会执行完整的生命周期：
1. 创建 MySQL 句柄对象
2. 发起 TCP 连接、完成 MySQL 身份认证
3. 执行 SQL 语句、处理结果
4. 关闭连接、释放资源
核心弊端：
- 频繁的 TCP 三次握手、四次挥手带来巨大网络开销
- MySQL 连接的身份认证、权限校验属于重操作，重复执行严重浪费 CPU 资源
- 高并发场景下，大量连接的创建与销毁会导致数据库连接数溢出，引发服务雪崩
1.2 连接池核心设计思想
- 核心本质：空间换时间，预先创建一批数据库连接并长期保持活跃，业务请求直接复用已有连接，避免重复建连开销。
- 核心价值：
- 统一管控连接数量，避免数据库连接数超出上限
- 统一封装数据库操作，业务层无需关心连接底层细节
1.3 线程绑定式连接池实现模型
该模型是 C/C++ 生态最常用的连接池实现方案，核心逻辑为一个干活线程绑定一个数据库连接，基于线程池实现任务调度。
1.3.1 核心组件
1. 任务队列：全局共享的阻塞队列，存储待执行的 SQL 任务
任务结构体包含两个核心字段：SQL 语句、回调函数对象
2. 多线程环境下通过互斥锁保证队列操作线程安全，通过条件变量实现任务等待与唤醒
干活线程池：预先创建的 N 个干活线程
1. 每个线程启动阶段就完成 MySQL 连接建立，线程生命周期内持有该连接句柄
2. 线程进入事件主循环：阻塞等待任务队列，取出任务后通过自身持有的连接执行 SQL
连接句柄：每个线程独立持有一个MYSQL*对象，全程绑定，不跨线程传递。
1. 关键约束：MySQL 连接句柄不是线程安全的，绝对禁止多线程共享同一个连接句柄并发执行 SQL，这也是 “一线程一连接” 设计的核心依据。
1.3.2 任务执行与回调机制
- 任务提交：业务层将 SQL 语句与回调函数封装为任务对象，推入任务队列
- 任务执行：工作线程取出任务，调用
mysql_query接口执行 SQL 语句 - 结果回调：
- 查询类 SQL：执行后通过
mysql_store_result获取结果集，将结果集传入回调函数，由业务层处理数据
1.3.3 连接保活与故障恢复
- 问题：MySQL 连接可能因网络波动、服务端超时等原因断开，直接执行 SQL 会报错
- 标准解决方案：
mysql_ping()检测连接有效性
- 若连接已断开，调用
mysql_real_connect重新建立连接 - 也可通过
mysql_options设置MYSQL_OPT_RECONNECT选项，开启客户端自动重连能力
1.3.4 单连接基础 API 示例
以下为 C++ 调用 MySQL C API 的基础连接实现，是连接池单线程的核心逻辑原型：
```
include
include
include
// 数据库连接配置
const std::string host = "localhost"; // 修正原笔记拼写错误
const std::string user = "connector";
const std::string passwd = "123456";
const std::string db = "conn";
const unsigned int port = 3306; // 修正原笔记端口错误，MySQL默认端口3306
int main() {
// 1. 初始化MySQL句柄
MYSQL* my = mysql_init(nullptr);
if (nullptr == my) {
std::cerr
这篇笔记就先到这里，后面用到新的思路或者发现有问题再补充。
评论 (0)
暂无评论