【数据存储】MySQL 连接池：服务端数据库访问的封装设计

实战应用：用在哪里

M2 每次查询都新建 MySQL 连接的话，握手开销（约 3~8ms）在高频访问下会成为瓶颈，连接数暴涨还可能触发数据库的 max_connections 限制。连接池预建一组长连接，业务借还使用，开销降到微秒级。适用于服务端所有数据库访问场景。

连接池实现：借还 + 健康检查

local Pool = { idle = {}, active = 0, maxIdle = 8 }

function Pool.acquire()
    local conn = table.remove(Pool.idle)
    if conn then
        if conn:ping() then return conn end     -- 健康检查失败则弃用
        conn:close()
    end
    return mysqlConnect(cfg)                    -- 池空则新建
end

function Pool.release(conn)
    if Pool.active > 0 then Pool.active = Pool.active - 1 end
    if #Pool.idle < Pool.maxIdle then
        Pool.idle[#Pool.idle + 1] = conn
    else
        conn:close()                            -- 池满归还，直接关闭
    end
end

借出前 ping 一次确认连接存活（MySQL 的 wait_timeout 会掐断闲置连接），失败则丢弃重建。maxIdle 按业务高峰的并发查询数设定，常见的 8~16 之间。

查询封装与防注入

业务不直接拼 SQL，统一走封装层的参数化接口：

function DB.query(sql, params)
    local conn = Pool.acquire()
    local result = conn:query(bindParams(sql, params))
    Pool.release(conn)
    return result
end

DB.query("SELECT * FROM players WHERE account = ?", { account })

参数化查询（? 占位符绑定）同时解决注入与转义两个问题。三条纪律：查询必须带索引条件（配合复合索引篇）；大结果集加 LIMIT 分页；写操作全部走事务或幂等设计。

监控与调参

池的三个监控指标：活跃连接数（长期贴着 maxIdle 说明池太小）、借出等待次数（大于 0 就要扩池）、ping 失败次数（网络或数据库稳定性信号）。某 996 服务端接入连接池后，高频查询的平均耗时从 7.8ms 降到 0.6ms，MySQL 的 threads_connected 从峰值 300 回落到稳定 12——连接池是数据库访问层的第一优先级基建。

连接池的健康检查放在借出时机而非定时轮询，省去空闲期的无谓探活。数据库侧的 wait_timeout 要大于池内最长闲置时间，两侧参数对齐后，ping 失败率会稳定在万分之一以下。nn## 事务与超时的配套nn多语句写入（发放礼包涉及物品与流水两张表）必须包在事务里，封装层提供 withTransaction(fn) 入口：借出连接、开启事务、执行回调、无错提交、有错回滚。事务内的查询与写入共用同一连接，混用池内其他连接会读到未提交状态。查询超时统一设为 5 秒，超时后该连接必须销毁重建，复用超时连接是连接池最常见的隐性故障源。