数据库连接泄漏完全指南:从一次"服务跑着跑着就 too many connections 卡死"看懂连接池、归还与事务

2022 年我做一个 Web 后端服务,每个请求进来都要查几次数据库——查用户、查订单、查配置。用数据库这件事,我压根没多想。第一版我做得很省事:用数据库,不就是拿一个连接、执行 SQL、把结果拿回来?需要数据时,我 connect() 拿个连接,execute() 把 SQL 发过去,fetchone() 把结果取回来,就完事了。本地开发时——真不错:我点几下页面,每个请求稳稳查到数据,响应又快又准,几行代码搞定。我心里很踏实:"用数据库嘛,不就是连上、查、拿结果?"可等这个服务真正上线、扛起每天几万次请求,一串问题冒了出来。第一种最先把我打懵:服务跑着跑着,数据库突然报 too many connections,新请求全部卡死,我只能重启,可过几个小时又卡死。第二种最难缠:我发现某个接口抛异常的那条路径上,连接根本没还回去,每走一次就漏掉一个连接。第三种最隐蔽:有个慢查询占着一个连接十几秒不撒手,高峰期连接全被这种慢查询占着,正常的快查询排着队都借不到连接。第四种最莫名其妙:一段代码忘了提交事务,连接还回池子时还挂着一个没结束的事务,下一个借到它的请求行为诡异——读到的是旧数据,或者干脆一直卡在锁等待上。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"用数据库,就是拿一个连接、执行 SQL、把结果拿回来"。这句话漏掉了一整个最关键的步骤——"还"。我脑子里,数据库连接就像一个我随手 new 出来的普通对象:要用就造一个,用完了它自己会消失。可数据库连接根本不是这种东西。它是一项"借来的、稀缺的、必须归还的资源"。稀缺,是因为数据库服务器能同时维持的连接数,有一个明明白白的硬上限——几十、上百,到顶就是到顶,再多它就拒绝你。借来的,是因为在一个像样的服务里,连接由一个"连接池"统一管着:进程启动时池子里备好固定的一批连接,所有请求都来这里"借",借走一个池子就少一个。必须归还,是因为我借出去的每一个连接,都得在用完之后,完完整整、干干净净地还回池子里——只有还回去了,它才能被下一个请求借走。我第一版所有的麻烦,根上都是同一件事:我只惦记着"拿来用",彻底漏掉了"用完必须还、必须及时还、必须以干净的状态还"。一个连接借了不还,就是一次"泄漏";泄漏一点一点地把池子掏空,池子空了,整个服务就借不到连接、彻底卡死。真正用对数据库连接,核心不是"拿连接、执行、拿结果",而是把连接当作一项借来的稀缺资源来对待:从池子里借,用 with 兜底保证它在任何路径上都被归还,归还前把事务干净地了结,再用超时防止它被一条慢查询长期霸占。这篇文章就把数据库连接管理梳理一遍:为什么"拿来就用"是错的、连接池是什么、怎么用 with 保证归还、事务该怎么干净了结、慢查询超时怎么设,以及连接健康检查、泄漏监控这些把连接管理真正做扎实要避开的坑。

问题背景

先把那串问题的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。

现象:一套"拿连接、执行 SQL、拿结果就行"的数据库代码,在真正扛起线上流量后冒出一串问题:服务跑着跑着报 too many connections,新请求全部卡死,重启几小时后复发;某个接口抛异常那条路径连接根本没还,每走一次漏一个;一条慢查询霸着连接十几秒,高峰期正常查询全在排队借不到连接;一段代码忘了提交事务,连接带着悬空事务还回池子,毒害了下一个借用者。

我当时的错误认知:"用数据库,就是拿一个连接、执行 SQL,把结果拿回来。"

真相:这个认知错在它把"数据库连接"当成了一个用完即弃的普通对象。在我脑子里,连接就像我随手 new 出来的一个临时变量——要用就造,出了作用域它自己就没了,我不用操心。可连接完全不是这种东西。它的真实身份是一项"借来的、稀缺的、必须归还的资源"。稀缺:数据库服务器能同时维持的连接数有一个硬上限,这个数字不大,撞上了它就直接拒绝新连接。借来的:正经服务里连接由连接池统一管理,进程启动时备好固定的一批,所有请求都来"借"。必须归还:借走的每一个连接,用完都得完整、干净地还回池子,还回去了才能给下一个请求用。开头那四个问题,根上全是"只想着借、漏掉了还":太多连接卡死,是因为我不停地新建连接、从不归还,直到撞穿硬上限;异常路径漏连接,是因为我的归还代码只写在"一切顺利"的那条路上;慢查询霸占连接,是因为我没意识到"连接被长期占着不放"和"借了不还"一样是泄漏;悬空事务毒害下一个人,是因为我归还连接时没把它身上的事务清理干净。问题的根子清楚了:这不是"某条 SQL 写错了"的小毛病,而是要换一个根本的认知——数据库连接是借来的稀缺资源,用对它,就是要保证每一个借出去的连接,都在任何情况下被及时地、干净地归还。

要把数据库连接管理做对,需要几块认知:

• 为什么"拿来就用"是错的——连接是借来的稀缺资源,不是用完即弃的对象;
• 连接池——进程启动时备好固定的一批连接,所有请求向它借;
• 归还兜底——用 with 保证连接在任何路径(包括抛异常)上都被还回;
• 事务了结——归还前必须 commit 或 rollback,不留悬空事务;
• 查询超时——给每条查询设上限,别让慢查询长期霸占连接;
• 连接健康检查、泄漏监控这些工程坑怎么处理。

一、为什么"拿连接、执行 SQL、拿结果"是错的

先把这件最根本的事钉死:"拿来就用"错在它脑子里有一幅错误的图景——它把数据库连接,想象成一个"我随手造、用完就自动消失"的轻飘飘的小对象。这幅图景之所以危险,是因为它把"连接"这个词里"稀缺"和"要归还"这两层意思整个抹掉了。一个普通对象,比如一个字符串、一个列表,你要多少造多少,内存够就行,用完了垃圾回收会替你收拾;造它、弃它,都没有代价。可一个数据库连接,它的另一头连着的是数据库服务器进程里一份真实的、有限的资源——服务器要为每一个连接分配内存、维护会话状态,所以它能同时撑住的连接数是被死死限制住的。这意味着两件事:第一,你不能无限地造连接,造到那个硬上限,数据库就翻脸拒绝;第二,你用完一个连接,必须主动把它"还"掉、让它能被复用,因为它不像普通对象那样弃之无害——一个借出去没还的连接,会一直占着服务器那份稀缺资源不放。所以正确的图景是:连接不是你"拥有"的,而是你从一个数量固定的池子里"借"的;借和还,必须成对出现。把"我造一个连接"换成"我借一个连接、并且我欠着一次归还",你才算站到了做对连接管理的起点上。

下面这段代码,就是我那个"本地点点没事、上线就卡死"的第一版:

# 反面教材:把数据库连接当成"拿来就用"的东西,漏掉了"还"
import psycopg2

def get_user(user_id):
    conn = psycopg2.connect(DB_URL)          # 破绽 1:每次新建连接,不复用、也没有任何上限
    cur = conn.cursor()
    cur.execute("SELECT name FROM users WHERE id = %s", (user_id,))
    row = cur.fetchone()                     # 破绽 2:这一行一旦抛异常,下面的 close 就跑不到
    conn.close()                             # 破绽 3:归还只写在"一切顺利"这一条路上
    return row[0]

这段代码在本地开发时表现不错,因为本地的"流量",其实是"可信而稀疏"的——是我自己点几下页面,每次只有一两个请求,而且我点的都是能正常查到数据的路径。我亲手扮演了一个温和的用户:连接建一个用一个,从不并发地建一大把;每个请求都顺顺利利,从不抛异常,于是那行 conn.close() 每次都执行得到。代码恰好一路平安,你看不出任何破绽。它的问题不在某一行语法上——connect()、execute()、close(),语法都对——而在它对连接这项资源,只做了"借"(其实是"造"),归还做得既不可靠、又不完整:它每次都新建连接、永不复用(破绽 1,迟早撞穿数据库的硬上限),它把归还写在了会被异常跳过的位置(破绽 2、3,出一次错就漏一个连接)。本地我自己点,请求稀疏又顺利,这些缺陷恰好都没被触发;一上线、流量一密、再赶上几个异常,它们会被逐一击穿。问题的根子清楚了:做对连接管理,第一步不是换个查询写法,而是承认"连接是借来的、必须可靠归还的稀缺资源",然后把"造了不管"换成"从池子借、用 with 保证还"。下面五节,就是这件事怎么落地。

二、连接池:进程启动时备好,所有请求向它借

先解决"每次新建连接"这个破绽。办法是连接池:进程一启动,就一次性建好固定数量的一批连接放进池子;之后所有请求不再自己建连接,而是统一向池子借:

from psycopg2 import pool

# 连接池:进程启动时一次性建好一批连接,之后所有请求都从这批里借、用完还
DB_POOL = pool.ThreadedConnectionPool(
    minconn=2,               # 池子里至少常备 2 个连接,随时待命
    maxconn=20,              # 硬上限:同一时刻最多借出 20 个,借光了后来者就排队等
    dsn=DB_URL,
)

这里的认知要点是:连接池的本质,是给"连接"这项稀缺资源,加一个统一的、有总量管制的"出借窗口"。要理解它为什么必须存在,得先想清楚两个代价。第一个代价是"建连接本身很贵"。建立一个数据库连接,不是凭空造个对象,它要走一次完整的网络握手、要做身份认证、数据库那头还要为这个会话分配资源——这一套下来是毫秒级甚至更久的开销。反面教材里每个请求都 connect 一次,等于把这份昂贵的开销摊到了每一个请求头上。连接池把这批连接在启动时就建好、之后反复复用,这份建立开销就只在启动时付一次。第二个代价、也是更要命的,是"连接总量必须被管住"。数据库服务器的并发连接数有硬上限,如果每个请求都自顾自地新建连接,流量一大,瞬间并发的连接数就会毫无节制地往上冲,直接撞穿那个上限,数据库开始拒绝一切新连接——这就是 too many connections。连接池的 maxconn 就是替你把这道闸门焊死:它向数据库要的连接总数,永远不会超过 maxconn 这个你设定的、安全地小于数据库硬上限的数字。当 20 个连接全被借走、第 21 个请求来借时,池子不会去新建第 21 个连接,而是让这个请求"排队等"——等到有人归还。注意这个"排队等"是关键的一环:它意味着连接池在高负载下,是用"让请求多等一会儿"来换"绝不冲垮数据库",这是一种主动的、安全的降级。所以连接池给你的不只是性能,更是一个总量上的保护罩。一句话:连接池让昂贵的连接被复用,更让连接总量被一个硬上限管死。有了池子,接下来的关键就是——借了之后,怎么保证一定还得回去。

三、用 with 兜底:让"归还"在任何路径上都执行

有了池子,核心问题就变成:从池子借出来的连接,怎么保证用完一定还回去——哪怕中途抛了异常。答案是用上下文管理器(with)把"借"和"还"绑成一对,让"还"这个动作落在 finally 里:

import contextlib

@contextlib.contextmanager
def borrow_conn():
    """借一个连接,用完无论成功还是失败都还回池子 —— 这就是'还'的兜底。"""
    conn = DB_POOL.getconn()                 # 从池子借出一个
    try:
        yield conn                           # 把连接交给 with 块里的代码用
    finally:
        DB_POOL.putconn(conn)                # finally:无论 yield 里出没出异常,都把它还回去

有了这个 borrow_conn,所有查询都套在它的 with 块里——借、用、还,三步一个都不会少:

def get_user_safe(user_id):
    """借、用、还 —— 三步齐全。借到的连接,一定会被还回去。"""
    with borrow_conn() as conn:              # with 进入时'借',退出时(连同异常)自动'还'
        with conn.cursor() as cur:           # 游标也用 with,块结束自动关闭
            cur.execute("SELECT name FROM users WHERE id = %s", (user_id,))
            row = cur.fetchone()
    return row[0] if row else None

这里的认知要点是:这一节要解决的,是反面教材里最致命的那个破绽——归还代码写在了"会被异常跳过的位置"。要理解 with 为什么能根治它,先想清楚普通写法错在哪。你把 conn.close 写在函数体的最后一行,你心里默认的是"代码会一行一行老老实实走到最后"。可一旦中间任何一行抛了异常,程序的执行就立刻从那里"跳走"了,它会顺着调用栈往上冒,后面的代码——包括你那行归还——统统被跳过。于是"出一次异常"就精确地等于"漏一个连接"。而真实的服务里,异常是必然会发生的:数据查不到、SQL 写错、数据库临时抖动、网络瞬断。也就是说,把归还写在末尾,等于赌"永远不出异常",这个赌注必输。with 上下文管理器根治的就是这件事:它的语义保证是——无论 with 块里的代码是正常走完,还是中途抛了异常,退出这个块时,finally 里的归还动作一定会被执行。borrow_conn 用 contextmanager 把 getconn 和 putconn 一头一尾绑在了一起,putconn 待在 finally 里,就拥有了"异常也拦不住它执行"的特权。这样一来,"借"和"还"就被焊成了一个不可分割的整体:你写下 with borrow_conn,就等于同时写下了"借"和"一定会还"。这是处理一切"必须成对出现"的资源(连接、文件、锁)的通用范式——不要靠自己记得在末尾收尾,要靠 with 把收尾这件事变成语言层面铁打的保证。还有个细节:代码里 cursor 也套了一层 with,同理,游标也是用完必须关的资源,让它也享受这份兜底。一句话:用 with 把'借'和'还'绑成一对,让归还落进 finally,异常就再也偷不走你的连接。连接能可靠归还了,可还有一个问题——还回去的连接,身上干不干净?这是下一节。

四、事务:连接必须以干净的状态归还

连接能还回去了,但还有一层:还回去的连接,必须是"干净"的——它身上不能挂着一个没了结的事务。凡是有写操作的地方,都要明确地 commit 或 rollback,把事务彻底了结:

def transfer(from_id, to_id, amount):
    """事务:要么两条都成,要么一条都不动 —— 归还连接前必须把事务彻底了结。"""
    with borrow_conn() as conn:
        try:
            with conn.cursor() as cur:
                cur.execute("UPDATE account SET balance = balance - %s WHERE id = %s",
                            (amount, from_id))
                cur.execute("UPDATE account SET balance = balance + %s WHERE id = %s",
                            (amount, to_id))
            conn.commit()                    # 两条都成了,提交 —— 事务干净结束
        except Exception:
            conn.rollback()                  # 中途出错,回滚 —— 绝不把半截事务留在连接上
            raise

下面这张图,把一个连接从借到还,完整的一生画出来:

这里的认知要点是:这一节要扭过来的观念是——"把连接还回池子"不等于"把连接收拾干净了"。上一节的 with 保证了连接这个对象一定会被 putconn 还回去,但它管不了这个连接"还回去时身上带着什么"。连接池是会复用连接的:你还回去的这一个,下一秒就可能被另一个请求借走。如果你还回去的连接上,挂着一个你既没提交、也没回滚的事务,那就等于把一颗雷传给了下一个借用者。为什么会有"悬空的事务"?因为很多数据库驱动,默认不是"每条 SQL 立刻生效"的——你执行一条 UPDATE,它其实是悄悄开了一个事务、把这条 UPDATE 记在里面,在你显式 commit 之前,这个改动既没真正落库、又一直占着相关的行锁。如果你用完连接、commit 这一步忘了写,这个事务就这么"悬"在连接上被还回了池子。下一个借到它的请求会撞见什么?它可能在一个它根本不知情的旧事务里跑——读到的是这个旧事务开始时的快照(数据像是"过期"的),或者它想改的那行正被这个悬空事务的锁占着,于是它莫名其妙地卡死在锁等待上。这种 bug 极其难查,因为出问题的请求和真正犯错的请求根本不是同一个。所以规矩是:任何借了连接做过写操作的代码,都必须在归还前给事务一个明确的了结——成功就 commit,出错就 rollback,二者必居其一。transfer 这个转账函数就是范本:它把两条 UPDATE 包在一起,全顺利就 commit,任何一步出错就 rollback 把已做的半截撤销干净。这同时也守住了事务最核心的承诺——原子性:转账要么"扣款和入账都成",要么"两边都没动",绝不允许"钱扣了没到账"这种半截状态存在。一句话:连接不仅要还,还要干净地还,归还前务必让事务有个明确的了结。连接能干净归还了,可还有最后一种泄漏没堵——连接被一条慢查询长期占着不放。

五、慢查询与超时:连接被长期占用,也是一种泄漏

还有一种泄漏很隐蔽:连接确实会被还回去,但被一条慢查询占着十几秒、几十秒才还。这期间它借给谁都没法用,效果和"借了不还"一样。对策是给每条查询设一个超时上限:

def query_with_timeout(sql, params, timeout_ms=3000):
    """给每条查询设超时 —— 一条慢查询不该无限期地霸占着一个连接。"""
    with borrow_conn() as conn:
        with conn.cursor() as cur:
            # 让数据库自己掐断:这条语句跑超过 timeout_ms 毫秒,就报错中止
            cur.execute("SET LOCAL statement_timeout = %s", (timeout_ms,))
            cur.execute(sql, params)
            return cur.fetchall()

除了查询超时,借连接本身也要设等待上限——池子被借光时,宁可快速失败,也不要让请求无限期挂住:

import time

def borrow_with_wait_limit(wait_ms=2000):
    """借连接也要设等待上限 —— 池子被占满时,宁可快速失败,不要无限期挂住。"""
    deadline = time.time() + wait_ms / 1000
    while True:
        try:
            return DB_POOL.getconn()         # 池里有空闲就立刻拿到
        except pool.PoolError:               # 池子被借光了,暂时借不到
            if time.time() > deadline:
                raise RuntimeError("连接池繁忙,等待连接超时,快速失败")
            time.sleep(0.05)                 # 等一小会儿再试

这里的认知要点是:这一节要把"泄漏"这个词的含义彻底想宽。前面三节防的是"借了不还"——连接对象始终没回到池子里。但还有一种危害一模一样、却不会被前面任何一道防线拦住的情况:连接最终是还了的,可它在被你拿着的那段时间里,被一条慢查询霸占了二十秒。在这二十秒里,这个连接对池子、对其他请求来说,和"丢了"没有任何区别——谁也用不上它。所以要把"泄漏"重新定义为:连接处于"无法被复用"状态的任何时长。借了不还,是无限长的泄漏;被慢查询占住二十秒,是二十秒的泄漏。一旦这么看,你就明白为什么超时是连接管理里不可缺的一环了。设想高峰期,池子里 20 个连接,如果每个都被一条十几秒的慢查询占着,那么在这十几秒里,整个服务实际可用的连接数就是 0,所有新请求全在排队——这和连接泄漏导致的卡死,现象一模一样。statement_timeout 就是给每条 SQL 装一个闹钟:跑得超过预定时间,数据库自己把它掐断、报错。这个掐断动作,顺着 with 链条,会立刻触发那个连接被归还——一条失控的慢查询,因此最多只能霸占一个连接 timeout_ms 那么久,而不是无限久。borrow_with_wait_limit 守的则是另一头:当池子真的被借空,一个新请求"等连接"也不能无限期地等——无限期地等,意味着这个请求会一直挂着,挂着的请求又拖住它自己占用的别的资源,卡顿会像滚雪球一样蔓延。给"等连接"也设一个上限,时间到了就快速失败、明确报错,这叫"快速失败优于慢慢拖死"——它把一个局部的拥堵,挡在了让它扩散成全局雪崩之前。一句话:连接被长期占用也是泄漏,用查询超时掐断慢 SQL、用借取超时挡住无限等待。主干都齐了,最后是几个把连接管理真正用到生产里才会撞见的工程坑。

六、工程坑:健康检查、泄漏监控、池子配置

主干之外,还有几个工程坑,不处理就会让你的连接管理在边角上出问题。坑 1:池子里可能躺着"死连接",借出前要探活。连接在池子里闲置久了,可能已经被数据库或中间的网络设备单方面掐断了,但池子并不知情。借出前先发一条 SELECT 1 探一探,死的就丢弃、换一个:

def get_healthy_conn():
    """借出前先 ping 一下 —— 池子里可能躺着已被数据库单方面掐断的死连接。"""
    conn = DB_POOL.getconn()
    try:
        with conn.cursor() as cur:
            cur.execute("SELECT 1")          # 探活:这条能跑通,说明连接还活着
        return conn
    except psycopg2.OperationalError:
        DB_POOL.putconn(conn, close=True)    # 死连接:丢弃掉,绝不还进池子去毒害下一个人
        return DB_POOL.getconn()             # 重新借一个

坑 2:连接泄漏要能被监控到,而不是等服务卡死才发现。给每次"借"记下时间戳,定期扫描——有连接被借出去超过某个时长还没还,极可能就是泄漏:

import threading

_borrowed = {}                               # 连接 id -> 借出时刻
_lock = threading.Lock()

def track_borrow(conn):
    with _lock:
        _borrowed[id(conn)] = time.time()    # 借出:记下时刻

def track_return(conn):
    with _lock:
        _borrowed.pop(id(conn), None)        # 归还:抹掉记录

def scan_leaks(max_hold_seconds=30):
    """定期扫描:有连接被借出超过 30 秒还没还,极可能是泄漏或卡死。"""
    now = time.time()
    with _lock:
        for cid, t in _borrowed.items():
            if now - t > max_hold_seconds:
                print(f"疑似连接泄漏:连接 {cid} 已被占用 {now - t:.0f} 秒未归还")

坑 3:进程退出前,要优雅地关闭整个池子。服务停止时,池子里那批连接不能就这么扔下不管——要主动全部关闭,否则会在数据库那头留下一批游离的连接:

def close_pool():
    """进程退出前,把池子里所有连接都规规矩矩地关掉。"""
    DB_POOL.closeall()                       # 一次性关闭池中全部连接,不留下游离连接

坑 4:池子大小不是越大越好。把 maxconn 设得很大,看似能扛更多并发,可数据库自己的连接数硬上限是死的——你所有服务实例的 maxconn 加起来,必须留足余量地小于数据库的上限。而且连接太多,数据库内部调度、锁竞争的开销反而拖慢一切。池子大小要按"数据库扛得住多少"和"实例有几个"算着定,不是拍脑袋往大了写。坑 5:连接池要配合多进程/多线程模型。很多 Web 框架是多进程(fork)跑的——连接绝不能在 fork 之前建好、再被子进程继承,父子进程共用一个连接会彻底乱套。连接池要在每个子进程启动之后各自初始化。坑 6:别在一个事务里夹着耗时的外部调用。事务一开,就占着连接、还可能占着行锁。如果你在 commit 之前夹了一个调外部 API、发消息之类的慢操作,这个事务就会拖很久,连接和锁都被它拽着。事务里只放数据库操作,耗时的外部调用挪到事务外。坑 7:只读查询和读写操作要分开对待。一个纯 SELECT 的查询不需要事务、不需要 commit;硬给它包一层事务,只是平白多占用连接时间。读写分离的架构里,只读查询还应该走只读库的连接池。坑 8:ORM 不会自动帮你管好连接。用了 ORM 不等于高枕无忧——ORM 的 session/会话同样是借来的连接的包装,同样必须在请求结束时明确关闭或归还。很多 ORM 连接泄漏,正是因为以为"框架会自动处理"而没在请求收尾时关掉 session。

关键概念速查

避坑清单

1. 把数据库连接当作借来的稀缺资源,不是用完即弃的普通对象。
2. 用连接池,进程启动时备好固定一批,所有请求向池子借,不每次新建。
3. maxconn 设成留足余量地小于数据库硬上限,借光后让请求排队。
4. 借连接一律套 with 上下文管理器,让归还落进 finally,异常也照还。
5. 游标 cursor 同样用 with 包住,用完自动关闭。
6. 做过写操作的连接,归还前必须 commit 或 rollback,绝不留悬空事务。
7. 给每条查询设 statement_timeout,别让慢查询长期霸占连接。
8. 借连接本身也设等待上限,池子借光时快速失败,不无限期挂住。
9. 借出连接前先 SELECT 1 探活,死连接丢弃换新,不毒害下一个人。
10. 给每次借连接记时间戳定期扫描泄漏,进程退出前优雅关闭整个池子。

总结

回头看那串"服务跑着跑着 too many connections 卡死、异常路径漏连接、慢查询霸占连接、悬空事务毒害下一个人"的问题,以及我后来在连接管理上接连踩的坑,最该记住的不是某一个函数的写法,而是我动手前那个想当然的判断——"用数据库,就是拿一个连接、执行 SQL、把结果拿回来"。这句话错在它漏掉了一整个最关键的步骤——"还"。我以为连上数据库、把 SQL 发过去、把结果取回来,这件事就办成了。可我忽略了一件最要紧的事:数据库连接不是我随手 new 出来、用完就自动消失的普通对象,而是一项借来的、稀缺的、必须归还的资源。数据库能同时维持的连接数有一个死的硬上限;一个像样的服务里,连接由连接池统一出借;我借出去的每一个连接,都欠着一次归还,而且必须在任何路径上、以干净的状态、及时地归还。我第一版的错,就是只写了"借和用",把"还"这件事,要么彻底漏掉(每次新建从不复用)、要么写在了会被异常跳过的位置、要么还回去时身上还挂着没了结的事务。这个错配,本地开发时根本看不出来——因为本地的流量是我自己点出来的,稀疏、温和、还都走顺利路径,连接建一个用一个、每次都还得掉,代码恰好一路平安;它只会在真正上线、扛起密集流量、还赶上一堆异常和慢查询时,以整个服务卡死的方式爆出来。

所以做对数据库连接管理,真正的功夫不在"写一条查询语句"那几行上。执行 SQL 本身不难。真正的功夫,在于你要从一开始就承认"连接是借来的稀缺资源",然后为"它一定会被及时、干净地还回去"做足设计:你不能每次都新建连接,就用连接池在启动时备好一批、让所有请求来借,并用 maxconn 把总量焊死;你不能把归还赌在"代码顺利走到最后",就用 with 把借和还绑成一对、让归还落进 finally;你不能让连接带着悬空事务还回去,就在归还前明确地 commit 或 rollback;你不能让一条慢查询长期霸占连接,就给每条查询设 statement_timeout、给借连接设等待上限;而到了死连接探活、泄漏监控、池子配置这些边角上,你还要处处守住,别让连接又在某个角落漏掉。这篇文章的几节,其实就是顺着这套规矩展开的:先想清楚"拿来就用"为什么错,再讲连接池、with 兜底归还、事务了结、查询超时,最后是健康检查、泄漏监控、池子配置这几个把连接管理守扎实的工程细节。

你会发现,数据库连接这件事,和现实里"图书馆怎么管它那批有限的书"完全相通。一个不靠谱的借书人会怎么做?他想看书了就跑去书架抽一本,看完随手往桌上一搁就走了,从不还回去;有时书看到一半被人叫走,他把书往兜里一塞、转身就忘了;他还一个人霸着一本最热门的书整整一个月不撒手。这样的人多了,图书馆那有限的几百本书,很快就全散落在各处、再也回不到书架上——后来的人想借,书架上空空如也,只能干等。而一个靠谱的图书馆怎么做?它有一个借还台,所有的书都从这里借、也都还到这里(这就是连接池);它规定一个人同时最多借几本,借满了就得先还了才能再借(这就是 maxconn 硬上限);它在你借书时就和你约定好归还日期,到期不还就催、就提醒(这就是 with 兜底和泄漏监控);它对热门的书设一个借阅时限,不许一个人无限期霸占(这就是查询超时);它还在书还回来时检查一下有没有破损、有没有夹着别的东西(这就是连接探活和事务了结)。同样是管一批有限的书,不靠谱的人脑子里只有"我要看书"这半件事,靠谱的图书馆脑子里装的是"借和还"这一整件事——每一本借出去的书,都必须能、也一定会回到书架上——差别不在"把书递出去这个动作本身难不难",只在管书的人心里有没有"这批书是有限的、借出去的每一本都得还回来"这根弦。

最后想说,数据库连接管理做没做对,差距永远不会在"本地开发、自己点几下页面"时暴露——本地那点"流量"就是你自己点出来的,稀疏、温和、还都走的是查得到数据的顺利路径,你那段"连上、查、拿结果"的代码恰好每次都把连接还得掉,响应又快又准,你自然觉得"用数据库嘛,连上查一下"一点问题都没有。它只在真实的、扛着密集并发、夹杂着大量异常和慢查询的线上环境里才显形。那时候它会用最难堪的方式给你结账:做不好,你会眼睁睁看着服务跑着跑着就报 too many connections、所有新请求一起卡死,会因为一条异常路径漏连接,让服务每隔几小时就要重启一次,会因为一条慢查询霸占连接,让高峰期的正常请求全在排队;而做对了,你的每一个连接都从池子里借、都在 with 的兜底下被及时归还、都以了结了事务的干净状态回到池子、都不会被任何一条慢查询长期霸占,无论线上流量多密、异常多频繁,那批有限的连接都在池子和借还之间稳稳地循环、谁都借得到。所以别等"服务又卡死了"那一刻找上门,在你写下访问数据库的第一行代码时就该想清楚:这个连接我是从池子借的吗、用完一定还得回去吗、异常路径上还得回去吗、还回去时事务了结了吗、它会被慢查询霸占吗,这一道道关口,我是不是都替这项借来的资源守住了?这些问题有了答案,你交付的才不只是一套"本地点点看着对"的代码,而是一个无论线上流量多大、异常多密,每一个连接都借得出、还得回、循环不息的、让人放心的系统。

—— 别看了 · 2026