Redis Stream 消息不再推进：从 Pending 积压到故障消费者安全接管
## 适用场景 本文适用于使用 Redis Stream 消费组承载异步任务、事件通知或轻量消息队列的系统。典型架构是生产者通过 `XADD` 写入 Stream，多个消费者用 `XREADGROUP` 拉取消息，业务成功后再执行 `XACK`。 当某个消费者在处理期间崩溃、被强制重启或网络中断时，已经投递但尚未确
Tag
#数据库
包含这个标签的文章。
MySQL 查询突然变慢：从统计信息失真到执行计划稳定的排查实践
## 适用场景 本文适用于 MySQL 8.0 使用 InnoDB 的生产环境。典型场景是 SQL 和索引近期都没有修改，但一次批量导入、归档删除或数据分布变化后，原本几十毫秒的查询突然变成数秒；`EXPLAIN` 显示优化器改走了低选择性索引、错误的连接顺序，甚至全表扫描。 这类问题容易被误判为“数据库负载太高”
PostgreSQL 表越删越大且查询变慢：从死元组取证到 autovacuum 治理
## 适用场景 本文适用于更新、删除频繁的订单、任务、消息、审计记录等 PostgreSQL 表。典型现象是：业务已经清理大量历史数据，但表文件没有缩小；索引扫描和备份越来越慢；监控中的磁盘使用持续上涨；执行 `VACUUM` 后空间仍未归还操作系统。 本文重点解决三个问题：如何确认膨胀来自死元组，为什么 auto
MySQL 深分页越来越慢：从 OFFSET 扫描到游标分页的改造实践
## 适用场景 本文适用于按时间倒序展示订单、流水、审计日志或消息列表的接口。典型特征是：第一页很快，翻到几千页后响应时间明显上升；数据库 CPU 和磁盘读取随页码增长；接口仍使用 `LIMIT offset, size`。 示例使用 MySQL 8.0，表结构如下： ```sql CREATE TABLE or
PostgreSQL 连接池耗尽：从 idle in transaction 到事务边界治理
## 适用场景 应用运行一段时间后，新请求开始等待数据库连接，接口 P99 持续升高，最终出现连接池获取超时或 PostgreSQL `too many connections`。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后
MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
MySQL binlog 突增吃满磁盘：从定位大事务到安全清理的排查实践
## 适用场景 MySQL 主库所在分区持续增长，`/var/lib/mysql` 已接近 100%，业务开始出现写入失败、事务提交变慢，甚至因为磁盘写满而触发只读保护。检查目录后发现大量 `mysql-bin.000xxx` 文件，但不能直接删除：binlog 仍可能被复制从库、增量备份或审计流程使用。 本文适用
Django 生产迁移卡住：从锁等待取证到可回滚发布的排查实践
## 适用场景 生产环境执行 `python manage.py migrate` 后长时间没有结束，应用发布流水线被阻塞；或者迁移最终报出 `Lock wait timeout exceeded`、`OperationalError`。这类问题常见于 Django + MySQL/InnoDB：迁移本身很短，却在等
MySQL 死锁频发：从现场取证到有边界重试的排查与治理实践
## 适用场景 业务接口偶发返回 `Deadlock found when trying to get lock`（错误码 1213），订单、库存、账户余额或状态流转等事务写入失败；重试后通常成功，但高峰期错误数明显上升。本文以 InnoDB 为例，给出一套可在生产环境执行的取证、定位和治理流程。 死锁不是数据库“
MySQL 联合索引顺序不匹配导致慢查询的排查与优化实践
## 适用场景 业务表按租户、状态和创建时间查询列表。数据量从几十万增长到千万级后，接口 P95 延迟突然升高；应用监控中数据库耗时占比明显增加，但 CPU 和磁盘利用率并不一定很高。 本文以常见的订单列表为例，说明如何确认“建了索引却没有用好”的联合索引问题，并在不影响线上写入的前提下完成优化。 ## 现象描述