PostgreSQL 并发建索引失败留下 INVALID:从等待取证到在线修复
适用场景 本文适用于 PostgreSQL 13 及以上版本的生产库:为了避免普通 CREATE INDEX 长时间阻塞写入,运维或开发人员改用 CREATE INDEX CONCURRENTLY,但命令执行数十分钟后失败、被取消,或者发布系统超时退出。重新执行时又提示索引已存在,查询计划却仍然走顺序扫描。 本文重点处
Tag
包含这个标签的文章。
适用场景 本文适用于 PostgreSQL 13 及以上版本的生产库:为了避免普通 CREATE INDEX 长时间阻塞写入,运维或开发人员改用 CREATE INDEX CONCURRENTLY,但命令执行数十分钟后失败、被取消,或者发布系统超时退出。重新执行时又提示索引已存在,查询计划却仍然走顺序扫描。 本文重点处
适用场景 商品详情、活动配置、首页聚合数据和权限策略等读取接口,通常会把查询结果缓存在 Redis 中。平时数据库负载很低,一旦某个热点键过期,大量并发请求却可能同时回源,几百毫秒内把连接池占满,最终形成接口超时、重试放大和数据库雪崩。 本文讨论的是单个或少量热点键失效导致的缓存击穿。如果大量键在同一时间过期,属于缓存
配置热更新看起来只是“重新读一次文件”,但在高并发服务里,它实际上是一次共享状态切换。如果更新协程直接修改正在被请求协程读取的 map、切片或结构体字段,轻则读到新旧配置拼接出的混合状态,重则触发 concurrent map read and map write,让整个进程退出。 本文以一个会动态调整上游地址和超时时
适用场景 本文适用于 Prometheus 通过 remote_write 把指标发送到 Thanos Receive、Grafana Mimir、VictoriaMetrics 或其他远端存储的场景。典型问题是本地抓取仍然正常,Prometheus 查询近期数据也没有明显异常,但远端查询、告警或长期存储中的数据逐渐落
适用场景 一个常驻的 Python API、消费者或定时任务进程,刚启动时只占用几百 MB,运行数小时后内存持续上涨。请求结束后内存没有明显回落,重启可以暂时恢复,但过一段时间又出现同样问题。监控最终触发容器 OOMKilled,或节点开始频繁交换内存。 本文针对“对象仍被 Python 引用”的增长场景,演示如何用标
适用场景 本文适用于 MySQL 8.0 使用 InnoDB 的生产环境。典型场景是 SQL 和索引近期都没有修改,但一次批量导入、归档删除或数据分布变化后,原本几十毫秒的查询突然变成数秒;EXPLAIN 显示优化器改走了低选择性索引、错误的连接顺序,甚至全表扫描。 这类问题容易被误判为“数据库负载太高”。真正需要回答
适用场景 本文适用于更新、删除频繁的订单、任务、消息、审计记录等 PostgreSQL 表。典型现象是:业务已经清理大量历史数据,但表文件没有缩小;索引扫描和备份越来越慢;监控中的磁盘使用持续上涨;执行 VACUUM 后空间仍未归还操作系统。 本文重点解决三个问题:如何确认膨胀来自死元组,为什么 autovacuum
适用场景 本文适用于按时间倒序展示订单、流水、审计日志或消息列表的接口。典型特征是:第一页很快,翻到几千页后响应时间明显上升;数据库 CPU 和磁盘读取随页码增长;接口仍使用 LIMIT offset, size。 示例使用 MySQL 8.0,表结构如下: CREATE TABLE orders ( id BIGIN
适用场景 应用运行一段时间后,新请求开始等待数据库连接,接口 P99 持续升高,最终出现连接池获取超时或 PostgreSQL too many connections。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高,重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”,而是业务代码开启事务后没有及时提交或
适用场景 FastAPI 服务平时响应正常,但只要某个文件处理、旧版 SDK 调用或报表计算接口并发升高,健康检查、登录和其他无关接口也一起变慢。CPU、内存和数据库连接数未必异常,扩容 Uvicorn worker 后只能暂时缓解。 这类问题常见于 async def 路由中直接调用同步阻塞函数。本文给出一个可复现的