Python asyncio场景MySQL连接池并发超限处理与最优配置咨询

当前方案的问题 #

你的实现不是最优解，存在以下明显缺陷：

• 你使用的mysql-connector是同步驱动，在asyncio单线程架构中，同步的数据库连接、查询操作会阻塞整个事件循环，导致bot其他请求全部卡住，完全浪费了异步架构的性能优势
• 裸except捕获逻辑不合理：除了连接池满的报错外，数据库实例宕机、配置错误、权限不足等异常都会被捕获，此时触发新建临时连接的逻辑不仅无法解决问题，还会疯狂创建无效连接耗尽服务器资源
• 无限制创建临时连接存在风险：MySQL服务端默认max_connections仅为151，峰值并发过高时大量临时连接会打满数据库连接上限，导致所有业务都无法连接数据库
• 异常场景下存在连接泄漏风险：如果查询执行过程中抛出异常，现有逻辑不会执行con.close()，会导致池连接或临时连接一直占用无法释放。

更优的实现方案 #

推荐按以下优先级优化：

1. 替换为异步MySQL驱动：改用aiomysql这类原生支持asyncio的驱动，自带异步连接池实现，查询过程不会阻塞事件循环，适配你的discord bot架构，示例核心逻辑如下：

import aiomysql

pool = None

async def init():
    global pool
    pool = await aiomysql.create_pool(
        host=dbconfig['host'],
        port=dbconfig['port'],
        user=dbconfig['user'],
        password=dbconfig['password'],
        db=dbconfig['db'],
        maxsize=16, # 调整为合适的大小
        autocommit=True
    )

async def do_work():
    async with pool.acquire() as con:
        async with con.cursor() as cur:
            await cur.execute("你的SQL语句")
            result = await cur.fetchall()
    # 上下文管理器会自动归还连接到池，无需手动close

2. 取消临时连接 fallback 逻辑：连接池满时优先让请求等待连接释放，可设置等待超时时间，超时后再返回业务报错或降级逻辑，避免打满数据库连接。
3. 窄化异常捕获范围：如果要保留临时连接逻辑，仅捕获连接池满的特定异常（如mysql.connector.errors.PoolError），避免掩盖其他故障。

MySQL连接池理想大小设置规则 #

连接池并不是越大越好，过高的连接数会导致MySQL上下文切换、锁竞争的开销大幅上升，反而降低吞吐量，设置时参考以下规则：

• 基础公式参考：理想连接数 = (CPU核心数 * 2) + 磁盘数量，这是针对CPU密集型查询的通用基准，如果你的查询都是简单的短查询，可适当上浮但不要超过该值的2倍
• 结合业务压测调整：从8~16的初始值开始压测，逐步提升连接数，观测吞吐量和查询延迟，当吞吐量不再随连接数上升而提升时，就是最优的连接池大小
• 预留余量：连接池最大大小不要超过MySQL服务端max_connections的80%，预留连接给管理员操作、其他业务使用
• 适配异步架构：你是单线程asyncio应用，同一时间并行执行的查询数不可能超过事件循环的调度上限，连接池大小不需要超过32，多数场景下8~16就足够支撑数千QPS的短查询需求。

内容的提问来源于stack exchange，提问作者Shubham