-
从 PostgreSQL 15 → 16 + Citus 12 + pgvector 0.7 + Patroni 4 全栈现代化 27 天踩坑录:10 反模式 + 12 修法
52 工程师 27 天把 17 个数据集群从 PG 15 + Citus 11 + pgvector 0.5 升级到 PG 16 + Citus 12 + pgvector 0.7 + Patroni 4 + Debezium 2.6,踩了 10 个反模式 + 6 次回滚 + 1 次 P0 + 3 次 P1,沉淀 12 套修法 + 28 个数据库工程化议题。- 2
- 0
-
MySQL UPDATE 8000 万行被 kill 后 rollback 90 分钟主库锁死 3 小时的真实事故复盘:InnoDB 回滚机制 + 拆批策略 + 10 条治理纪律
2026 年 2 月一次 UPDATE 8000 万行的合规任务跑了 4 小时,DBA 担心影响早高峰执行 KILL,结果 rollback 比正向执行更慢——花 90 分钟才完成,主库锁死 3 小时,业务超时 41 万笔,直接损失 80 万。复盘 InnoDB 回滚单线程机制 + 5 种大事务典型场景 + SafeBatchUpdater 框架 + 8 条工程纪律。- 4
- 0
-
PostgreSQL 索引设计完全指南:从一次"加 30 个索引写入腰斩查询还是 5 秒"看懂为什么 CREATE INDEX 远远不够
2020 年我接手一个 SaaS 客户关系管理系统 PostgreSQL 15 单库 800 张表最大表 customer_events 8000 万行用户反馈系统越来越慢一个查询从 50ms 涨到 8 秒老板天天追着问我以为加索引嘛简单在 user_id 加个 B-tree 在 created_at 加个 B-tree 在 status 加个 B-tree 一共加了 30 多个索引重启应用查询确…- 0
- 0
-
PostgreSQL 索引设计完全指南:从一次"加索引锁表 4 分钟业务停摆"看懂为什么 CREATE INDEX 远远不够
2023 年我们做一个 SaaS 数据分析平台后端用 PostgreSQL 14 主库一台 32C 128G 加两台只读从库业务初期 100 万订单 1000 万事件一切都很流畅查询都在 50ms 内半年后数据涨到 1 亿订单 8 亿事件我们陆续踩了一堆坑第一种最让我傻眼一个看似普通的 ORDER BY created_at DESC LIMIT 10 查询没建索引前 5 秒加了 b-tree 索…- 5
- 0
-
PostgreSQL bloat 治理实战:1.2 亿行表从 380GB 压到 152GB
1.2 亿行 orders 表磁盘占 380GB,死元组占 47%,查询 p99 飙到 10 秒。本文实录 PG MVCC 膨胀定位 + pg_repack 在线清理 + autovacuum 调优 + 长事务监控 + fillfactor + 分区化迁移全过程,附 VACUUM FULL / pg_repack / 分区三套方案对比。- 2
- 0
DBA
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×