数据库连接池饥饿会造成什么现象，应该怎么修复？

典型现象是接口延迟在发布后立即断崖式恶化，同时容器副本数因自动扩容暴增，但吞吐量并没有相应提升。文中的案例是某版本把 MaxOpenConns 和 MaxIdleConns 都降到 1，而列表接口需要并发执行多个子查询，多条 SELECT 同时争抢仅有的 1 个数据库连接，大量请求在连接池上排队，单条 SELECT 的实际耗时被排队等待放大到 300ms ~ 3400ms，接口 P95 从不到 60ms 飙到 1875.8ms。修复方向有三点：把连接池参数恢复到合理值；移除查询路径中被误插入的不必要写入操作；给查询加上 100ms 级别的 context timeout，防止慢查询长时间阻塞。应急处置上，先回滚到上一个正常版本可以立即恢复延迟，再通过特性标记隔离问题版本。