PostgreSQL 连接池耗尽：从 idle in transaction 到事务边界治理
## 适用场景 应用运行一段时间后，新请求开始等待数据库连接，接口 P99 持续升高，最终出现连接池获取超时或 PostgreSQL `too many connections`。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后
Tag
#性能优化
包含这个标签的文章。
FastAPI 接口并发升高后全站变慢：阻塞调用卡住事件循环的定位与治理
## 适用场景 FastAPI 服务平时响应正常，但只要某个文件处理、旧版 SDK 调用或报表计算接口并发升高，健康检查、登录和其他无关接口也一起变慢。CPU、内存和数据库连接数未必异常，扩容 Uvicorn worker 后只能暂时缓解。 这类问题常见于 `async def` 路由中直接调用同步阻塞函数。本文给
MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
Redis 延迟偶发飙升：从 Hot Key 与 Big Key 定位到分阶段治理实践
## 适用场景 业务使用 Redis 承载登录态、商品详情、计数器或排行榜。平时接口稳定，但在促销、定时任务或某些请求集中到来时，应用开始出现 Redis 超时；监控中 `instantaneous_ops_per_sec` 并不一定很高，CPU 也可能没有持续满载。 本文以单实例或主从架构为例，说明如何区分 **
Python httpx 并发请求频繁 PoolTimeout：连接未释放与连接池参数的排查实践
## 适用场景 Python 服务或批处理脚本通过 `httpx` 调用第三方 HTTP API。流量上来后，应用日志开始出现 `httpx.PoolTimeout`，但目标接口的监控显示延迟正常；重启服务后短暂恢复，随后问题又出现。常见于 FastAPI/Django 的异步任务、数据同步程序和并发爬取工具。 本
MySQL 死锁频发：从现场取证到有边界重试的排查与治理实践
## 适用场景 业务接口偶发返回 `Deadlock found when trying to get lock`（错误码 1213），订单、库存、账户余额或状态流转等事务写入失败；重试后通常成功，但高峰期错误数明显上升。本文以 InnoDB 为例，给出一套可在生产环境执行的取证、定位和治理流程。 死锁不是数据库“
Celery 任务积压但部分 Worker 空闲：worker_prefetch_multiplier 引发分配不均的排查与治理
## 适用场景 使用 Celery + Redis/RabbitMQ 承担异步任务。队列中仍有大量待执行任务，但监控显示少数 Worker 忙碌、其余 Worker 空闲；或者短任务被长任务“压住”，整体延迟持续升高。本文以默认的 `prefork` 并发池和 RabbitMQ 为例，Redis broker 的排查
MySQL 联合索引顺序不匹配导致慢查询的排查与优化实践
## 适用场景 业务表按租户、状态和创建时间查询列表。数据量从几十万增长到千万级后，接口 P95 延迟突然升高；应用监控中数据库耗时占比明显增加，但 CPU 和磁盘利用率并不一定很高。 本文以常见的订单列表为例，说明如何确认“建了索引却没有用好”的联合索引问题，并在不影响线上写入的前提下完成优化。 ## 现象描述