标签频道
PostgreSQL
该标签下的文章、提问与讨论帖。
背景：我们正在评估分布式事务中间件的写入性能，需要对比PostgreSQL 16与MySQL 8.0在高并发场景下的表现 现象： 1. MySQL 8.0在MaxPoolSize=100时P99仍达1.2s（参考问题id=3277） 2.
一、现象与背景：批量写入场景下的性能瓶颈与选型困境 在高并发写入场景下，选择合适的数据库对于性能和稳定性至关重要。本文以一个实际的批量写入任务为例，对比了 PostgreSQL 16 与 MySQL 8.0 在不同批量大小和并发度下的写入性
一、现象或背景 做了 10 年数据库平台工程，最常被问的一句话是"这个查询慢，加个索引就好了吧？" 但加索引从来不是免费的。我亲历过三个典型的"加了索引反而更差"的事故： - 订单表加了第 9 个二级索引后，批量写入 P99 从 12ms
一、现象与背景：批量写入场景下的性能瓶颈与选型困境 在高并发写入场景下，选择合适的数据库对于性能和稳定性至关重要。本文以一个实际的批量写入任务为例，对比了 PostgreSQL 16 与 MySQL 8.0 在不同批量大小和并发度下的写入性
一、现象或背景：200k rows/s 写入下的性能与可靠性博弈 我负责一条实时 ETL 管道：Kafka 3.5（KRaft，3 broker，ISR=3）→ 自研消费服务（Go 1.22 + pgx v5.7，K8s 4 副本）→ Po
背景 我们正在使用 PostgreSQL 16 处理高并发写入场景（约 200 并发 INSERT/UPDATE 事务，单事务涉及 3~5 张表），但观察到锁争用导致 P99 延迟从 5ms 飙升至 200ms。已尝试调整 autovacu
【背景】 在高并发场景下，JDBC 驱动服务端取消 SQL 是常见需求（如超时/中断/取消），但 MySQL Connector/J 和 PostgreSQL JDBC 的实现差异容易引发踩坑。 【常见分歧】 1. MySQL Connec
背景：我们服务在双十一流量峰值时，发现部分写入请求在服务端被异常取消，导致数据丢失且无报错日志。 现象： 1. MySQL Connector/J 8.0.33 在 QPS 5000+ 时出现 3% 的写入失败率，抛出 "java.sql.
【背景】 在高并发场景下，JDBC驱动服务端取消SQL（如调用cancel()）是避免资源浪费的关键操作。但MySQL Connector/J与PostgreSQL JDBC在实现机制上存在显著差异，可能导致性能抖动或资源泄漏。 【常见分歧
现象或背景：高并发下 JDBC 驱动服务端取消 SQL 的实现差异 在双十一流量峰值时，我们发现部分写入请求在服务端被异常取消，导致数据丢失且无报错日志。具体表现为： - MySQL Connector/J 8.0.33 在 QPS 500
背景：我们服务单机 QPS 2.3 万时，发现 MySQL 8.0 驱动 8.0.33 在长连接池中会出现 SQL 被服务端取消的现象，而 PostgreSQL JDBC 42.6.0 无此问题。 现象： 1. MySQL 会抛出 java
背景：我们服务在双十一流量峰值时，发现部分写入请求在服务端被异常取消，导致数据丢失且无报错日志。 现象： 1. MySQL Connector/J 08.0.29 在高并发下出现 3% 的写入失败率 2. PostgreSQL JDBC 4
背景 维护一个 QPS 5000+ 的交易链路，下游 DB 层存在偶发 P99 300ms+ 的抖动。当上游超时后，发现 JDBC 连接池中仍有大量「孤儿工作」占用资源，导致线程池和连接池容量被拖垮。 现象 1. 使用 "Statement
【背景】 做了 10 年数据库平台工程，最常被问的一句话是"这个查询慢，加个索引就好了吧？" 但加索引从来不是免费的。我亲历过三个典型的"加了索引反而更差"的事故： - 订单表加了第 9 个二级索引后，批量写入 P99 从 12ms 涨到
«结论先行：PostgreSQL 的「auto plan cache」机制（named prepared statement 执行满 5 次后自动比较 generic plan 与 custom plan 的代价并择优切换）在参数分布倾斜时
背景 我负责一条实时 ETL 管道：Kafka 3.5（KRaft，3 broker，ISR=3）→ 自研消费服务（Go 1.22 + pgx v5.7，K8s 4 副本）→ PostgreSQL 16.2（单主库，32C128G，NVMe
问
Go pgx extended protocol 撞 PgBouncer transaction 模式：simple protocol 降级丢 P50、session 模式连接数爆——有没有第三条路？
背景 一个 Go 1.21 + pgx v5.5 的订单写入服务，K8s 部署 6 副本（每副本 4C8G），下游 PostgreSQL 15.4（16C64G，NVMe），中间套了一层 PgBouncer 1.21（transaction
文
标题
摘要