线上接口开始变慢。你第一反应是查数据库。慢SQL列表几乎是空的。大部分SQL都只有几十毫秒。数据库CPU也没有明显打满。可连接池监控却越来越奇怪Active Connection一路上涨。Idle越来越少。Pending Thread开始出现。最后很多请求不是卡在SQL执行而是卡在getConnection()最让人困惑的是SQL明明都很快为什么数据库连接还是迟迟不归还如果这时候直接让 ChatGPT、Codex“帮我优化SQL。”很可能方向就错了。因为连接池真正关心的不只是SQL执行了多久。而是一条连接从借出去到最终归还一共被占用了多久。一、先给核心判断SQL快不等于连接占用时间短很多人会把这两个时间混在一起。比如一条SQL执行30ms。看起来很快。但如果整个事务是拿连接。执行SQL。调用HTTP接口。处理业务逻辑。再执行第二条SQL。最后Commit。整个过程可能持续2秒。甚至5秒。这意味着虽然真正跑SQL只用了几十毫秒这条数据库连接却可能被这个请求占了几秒。所以真正应该看的不是SQL Duration而是Connection Hold Time——连接持有时间。二、最常见的现场事务里夹了远程调用比如代码逻辑大概是先查订单。然后调用支付接口。再更新状态。最后提交事务。如果整个方法被Transactional包住那数据库连接可能从第一次访问数据库开始就一直被占着。中间调用支付接口花了1.5秒。连接也跟着等了1.5秒。如果并发一上来20个线程。20个连接。大家全都拿着连接等HTTP。这时候数据库本身可能非常闲。但连接池已经满了。于是后面的请求全部卡在等连接。这就是为什么Database不忙不代表Connection Pool不忙。三、所以第一步不要先查慢SQL先看连接池四个指标我通常先看Active ConnectionIdle ConnectionPending / Waiting ThreadConnection Acquire Time如果出现Active长期接近Max。Idle接近0。Pending持续上涨。Acquire Time越来越高。那问题已经很明确应用拿连接的速度大于归还连接的速度。这时候继续盯数据库CPU很容易浪费时间。四、为什么单条SQL几十毫秒连接池还是能被拖满假设连接池大小20。每个请求真正SQL执行50ms。如果连接拿到以后立即执行、立即归还吞吐其实很高。但如果每个请求拿着连接平均2秒20个连接最多只能同时服务20个请求。第21个请求开始只能等。如果请求继续进来Pending就会越来越多。所以连接池容量真正受影响的是每个请求占用连接的总时间。而不是SQL自己执行多久。五、第二个高频原因事务边界太大很多项目里会出现这种写法一个Service大方法整个加Transactional然后这个方法里面做很多事情查数据库。调用RPC。计算。写日志。发消息。再更新数据库。从业务角度看“这是一整个流程。”但从资源角度看这可能意味着一条数据库连接被整个流程长期占用。事务越大锁持有时间通常越长。连接持有时间也越长。这时候连接池压力就会明显放大。所以排查连接池时一定要问Transaction到底从哪里开始到哪里结束不要只看SQL本身。六、真实边界场景连接泄漏还有一种情况就更直接。连接拿出来了。但某条异常路径没有正确关闭。或者ResultSet。Statement。Streaming Cursor没有释放。于是这些连接一直回不到池里。这种问题的特点通常是Active Connection缓慢上涨。Idle越来越少。但即使流量下降以后Active也不明显回落。这时候就要开始怀疑Connection Leak。很多连接池都有Leak Detection能力。例如可以监控一条连接被借出超过多少秒还没有归还。如果这种日志持续出现就很值得顺着调用栈查。七、Streaming Result也很容易让连接“看起来没问题其实一直占着”有些查询结果很多。为了避免一次性加载全部数据会使用流式读取。Cursor。边读边处理。这种方式本身没问题。但只要数据还没有读取完连接往往就不能归还。如果你一边读数据库一边做复杂计算。调用外部接口。写文件。那这条连接可能会被长时间占用。所以有时候SQL执行本身已经开始返回数据。但Connection仍然没有结束生命周期。这类场景特别容易被“没有慢SQL”误导。八、还有一种情况线程池比连接池大得多比如业务线程池有100个线程。数据库连接池只有20个连接。一旦100个任务同时进来20个拿到连接。剩下80个开始等。如果这些任务本身还包含远程调用、长事务等待会越来越严重。这时候你可能以为连接池太小。直接改成20 → 50。但问题可能只是被暂时推迟。因为数据库本身能不能承受50个并发连接还要另外判断。所以Thread Pool和DB Pool必须一起看。不能各调各的。九、为什么“把连接池调大”经常治标不治本这是最常见的第一反应。Active满20。那就改50。如果问题只是连接池确实偏小当然可能有效。但如果真正原因是长事务。连接泄漏。HTTP调用放在事务里。Streaming Result占用太久。那Pool变大以后只是原来20个请求一起卡。现在50个请求一起卡。甚至数据库压力变得更大。最终可能出现连接池不排队了。数据库开始排队。所以调大Pool之前一定要先回答为什么连接迟迟不归还十、最快排查顺序我一般按这7步遇到“没有慢SQL但连接池越来越满”我建议直接按这个顺序查。第一步看Pool状态确认Active、Idle、Pending、Max。第二步看Connection Acquire Time判断请求是不是已经开始大量等连接。第三步看事务耗时不是SQL耗时。是完整Transaction Duration。第四步看Connection Hold Time连接拿到以后到底多久才归还。第五步检查事务里有没有远程调用HTTP。RPC。消息。文件IO。第六步检查Leak看连接是否存在长时间不归还的异常路径。第七步再看线程池和数据库容量最后才决定Pool到底应该配多大。这个顺序比“先看慢SQL → 没有 → 调大连接池”要稳很多。十一、具体怎么修先看根因是哪一类如果是事务太大缩小事务边界。把非数据库操作尽量移出事务。HTTP / RPC夹在事务里尽量先完成远程交互再进入真正需要原子性的数据库阶段。Connection Leak补全关闭逻辑。检查异常路径。开启Leak Detection。Streaming Result占用过久缩短处理时间。分页。批次读取。不要边占连接边做大量非数据库工作。Pool确实偏小在确认数据库承载能力以后再合理调整。不是盲目翻倍。十二、还有一个很实用的判断流量下降以后Active会不会降下来这能快速区分很多问题。如果高峰过去以后Active很快从20降到3。Idle恢复。那更像瞬时并发 容量不足。如果高峰过去以后Active还长期维持19、20。那就要重点怀疑长事务。连接泄漏。卡死调用。未关闭资源。这个现象非常有用。十三、修完以后怎么验证不要只看“接口现在快了。”更应该重新制造原来的并发。然后观察Active是否会在峰值后回落。Pending是否减少。Acquire Time是否下降。Transaction P95 / P99是否下降。连接泄漏日志是否消失。数据库CPU、IO是否仍然健康。最重要的是Completed Request Rate能不能稳定高于进入速率。否则Queue和Pending迟早还会再涨。十四、一个典型修复前后的差异修复前连接池Max 20。Active长期20。Pending 80。SQL平均30ms。Transaction平均2.3s。修复以后把事务里的HTTP调用移出去。Transaction从2.3s降到180ms。结果即使连接池仍然是20Active峰值可能只到12。Pending直接接近0。这就说明真正的问题从来不是连接数量太少。而是每条连接占用得太久。十五、这种连接池排查Plus和Pro怎么判断如果你平时只是偶尔让 ChatGPT、Codex分析连接池监控。看看事务边界。检查一段Transactional代码。辅助判断是不是Leak。这种任务范围比较集中Plus通常已经够用。关键是把Evidence给完整Pool指标。事务耗时。线程池大小。DB Pool大小。代码调用链。远程调用位置。这些信息比只给一句“连接池满了”有用得多。如果你的日常已经变成持续排查数据库连接、线程池、事务、Redis、HTTP依赖。一个问题需要结合Trace。Thread Dump。连接池指标。数据库监控。应用代码。还要让Codex修改事务边界、补压测、做回归而且这种多轮工程任务每天都在发生那Pro会更适合。所以Plus还是Pro不看“连接池问题高级不高级。”而是看ChatGPT、Codex是不是已经长期参与完整的工程排障链路。偶发排查、短任务Plus通常够用。高频性能治理、多轮分析验证再考虑Pro。最后没有慢SQL为什么数据库连接池还是越来越满因为真正决定连接池压力的不只是SQL执行多久。而是每条连接到底被占用了多久。一个30ms的SQL完全可能因为长事务。HTTP调用。Streaming Result。连接泄漏让连接被占2秒、5秒甚至更久。所以以后看到Active越来越高。Pending越来越多。不要第一反应只去查慢SQL。先把Connection Acquire Time → Transaction Duration → Connection Hold Time → 外部调用 → Leak这一条链还原出来。很多“数据库不忙但连接池爆了”的问题真正根因往往就在这里。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。