PostgreSQL 表越删越大且查询变慢：从死元组取证到 autovacuum 治理
适用场景 本文适用于更新、删除频繁的订单、任务、消息、审计记录等 PostgreSQL 表。典型现象是：业务已经清理大量历史数据，但表文件没有缩小；索引扫描和备份越来越慢；监控中的磁盘使用持续上涨；执行 VACUUM 后空间仍未归还操作系统。 本文重点解决三个问题：如何确认膨胀来自死元组，为什么 autovacuum
Category
数据库
当前分类下的文章。
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 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后没有及时提交或