MySQL 连接池复用后请求行为漂移：会话状态泄漏的排查与复位实践
适用场景与现象 同一个接口在生产环境中偶发出现以下现象：有时写入没有立即提交，有时日期相差 8 小时，有时普通查询突然以更严格的事务隔离级别执行。重启应用后故障暂时消失，单独连接 MySQL 手工执行又无法复现。 这类问题常见于使用连接池的 Web 服务、异步任务和批处理程序。连接池归还的是可复用的物理连接，而 MyS
Tag
#数据库
包含这个标签的文章。
PostgreSQL 插入新数据却主键冲突：从序列漂移到安全校准的排查实践
适用场景 本文适用于 PostgreSQL 表使用 serial、bigserial 或 identity 列生成主键，但执行正常 INSERT 时仍出现主键重复的场景。常见诱因包括数据迁移、手工补数据、COPY 导入、只恢复表数据却漏掉序列状态，或者在不同环境之间合并数据。 典型表结构如下： CREATE TABLE
Redis Stream 消息不再推进：从 Pending 积压到故障消费者安全接管
适用场景 本文适用于使用 Redis Stream 消费组承载异步任务、事件通知或轻量消息队列的系统。典型架构是生产者通过 XADD 写入 Stream，多个消费者用 XREADGROUP 拉取消息，业务成功后再执行 XACK。 当某个消费者在处理期间崩溃、被强制重启或网络中断时，已经投递但尚未确认的消息不会重新出现在
MySQL 查询突然变慢：从统计信息失真到执行计划稳定的排查实践
适用场景 本文适用于 MySQL 8.0 使用 InnoDB 的生产环境。典型场景是 SQL 和索引近期都没有修改，但一次批量导入、归档删除或数据分布变化后，原本几十毫秒的查询突然变成数秒；EXPLAIN 显示优化器改走了低选择性索引、错误的连接顺序，甚至全表扫描。 这类问题容易被误判为“数据库负载太高”。真正需要回答
PostgreSQL 表越删越大且查询变慢：从死元组取证到 autovacuum 治理
适用场景 本文适用于更新、删除频繁的订单、任务、消息、审计记录等 PostgreSQL 表。典型现象是：业务已经清理大量历史数据，但表文件没有缩小；索引扫描和备份越来越慢；监控中的磁盘使用持续上涨；执行 VACUUM 后空间仍未归还操作系统。 本文重点解决三个问题：如何确认膨胀来自死元组，为什么 autovacuum
MySQL 深分页越来越慢：从 OFFSET 扫描到游标分页的改造实践
适用场景 本文适用于按时间倒序展示订单、流水、审计日志或消息列表的接口。典型特征是：第一页很快，翻到几千页后响应时间明显上升；数据库 CPU 和磁盘读取随页码增长；接口仍使用 LIMIT offset, size。 示例使用 MySQL 8.0，表结构如下： CREATE TABLE orders ( id BIGIN
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：迁移本身很短，却在等待另一条业务 SQL