PostgreSQL 事务与并发系列 · 第三期 锁机制与死锁处理实战 前两期我们深入了 MVCC 与快照隔离，知道了“读不阻塞写”。但有些场景必须靠锁来强制串行化。本期将带你掌握 PostgreSQL 中各类锁的用法、冲突关系、死锁成因与排查，并提供生产环境可用的监控脚本。 一、为什么有了 MVCC 还需要锁？ MVCC 主要解决了 读写冲突（读不阻塞写，写不阻塞读），但它无法解决 写写冲突 以及某些需要“绝对最新数据”的场景。 例如： 两个事务同时对同一行执行
PostgreSQL 事务与并发系列 · 第二期 深入 MVCC：可见性判断与事务快照揭秘 第一期我们建立了 ACID 和 MVCC 的基本概念。本期将掀开 MVCC 的引擎盖，剖析元组头部的 xmin/xmax、事务快照的内存结构，并通过实战案例看清“读已提交”与“可重复读”的本质差异。 一、回顾：MVCC 的核心思想 PostgreSQL 中，每一行数据（称为元组 tuple）在被修改时不会原地更新，而是插入一个新的行版本，旧的版本仍然留在数据页中。这些版本通过元组头部的两个事务 ID
PostgreSQL 事务与并发系列 · 第一期 从 ACID 到 MVCC：PostgreSQL 并发控制的核心思想 本系列将带你系统掌握 PostgreSQL 事务与并发的每一步。第一期从 ACID 原则谈起，揭开 MVCC 如何实现”读不阻塞写、写不阻塞读”。 一、引言 在关系型数据库的世界里，事务（Transaction）是数据一致性与并发控制的基石。PostgreSQL 之所以被公认为”业界最先进的开源关系型数据库”，其强大的事务处理能力和高并发支持功不可没。 理解
SQL 与查询优化（PostgreSQL 篇）· 第七期 查询缓存、连接池与中间件优化 从第一期到第六期，我们的焦点一直围绕单实例 PostgreSQL：执行计划、索引设计、连接算法、统计信息、物化视图与分区表，以及锁与并发控制。但是，当到达了几百万乃至上亿行数据之后，应用程序不仅查询复杂，连接数也可能成千上万。 本期我们跳出数据库内核，进入中间件层，探讨查询缓存、连接池和分布式中间件如何进一步提升系统的极限。 一、连接池 – 高并发的前提 1.1 为什么需要连接池？ 在 PostgreSQL 中，每一个新的客户端连接都会在服务器端 fork() 一个新的进程（Backend Process）。一个空闲的数据库连接，即使没有执行任何查询，也会占用大约 5-10
SQL 与查询优化（PostgreSQL 篇）· 第六期 锁与并发控制 – 查询优化的另一维度 前五期我们专注 SQL 本身：执行计划、统计信息、连接算法、高级 SQL、分区表，以及优化器调参。 但在高并发系统中，锁与事务往往成为性能瓶颈。本期深入 PostgreSQL 的锁机制、MVCC、Vacuum 原理，学会诊断锁冲突、优化高并发写入，让数据库在多用户环境下依然流畅运行。 一、PostgreSQL 的并发控制基石：MVCC PostgreSQL 没有使用传统的两阶段锁（2PL）来避免读写冲突，而是采用了 多版本并发控制（MVCC）。
SQL 与查询优化（PostgreSQL 篇）· 第五期 查询优化器内部机制与高级调参 前四期我们构建了完整的优化知识体系：执行计划、统计信息、连接算法、高级 SQL、物化视图与分区表。 本期我们钻进优化器的“黑盒”，剖析代价模型、参数开关、并行查询，甚至学会强制执行计划——当你比优化器更懂数据时，这些能力会让你如虎添翼。 一、优化器的工作流程回顾 PostgreSQL 优化器基于代价选择执行计划。流程如下： 解析与重写：SQL → 解析树 → 基于规则的重写（视图展开、常量折叠）。 生成路径：为每个表考虑不同的扫描路径（Seq Scan、Index Scan、Bitmap Scan），为每个
SQL 与查询优化（PostgreSQL 篇）· 第四期 物化视图、分区表与批量数据优化 前三期我们深入了执行计划、统计信息、连接算法与高级 SQL 能力。本期聚焦数据架构层面的优化：物化视图、分区表以及批量数据处理技巧。 当单表数据量达到亿级，日常查询和分析变得缓慢时，这些技术能让你在不改业务代码的前提下，获得数量级的性能提升。 一、物化视图 – 预计算的艺术 1.1 什么是物化视图？ 普通视图只是保存一条查询规则，每次访问都会重新执行查询。而物化视图（Materialized View） 会实际存储查询结果，就像一张真实的表。你可以对其创建索引、分析统计信息，甚至进行 ANALYZE。 适用场景： 报表统计（复杂聚合、多表连接），数据不需要绝对实时（容忍秒级或分钟级延迟）。
SQL 与查询优化（PostgreSQL 篇）· 第三期 连接优化与统计信息深度调优 经过前两期，你已经能读懂执行计划、用好窗口函数与 CTE。本期进入多表连接优化的核心地带，并深挖优化器的“大脑”——统计信息。 我们将剖析三种连接算法背后的代价模型，学会用扩展统计信息解决多列关联的基数误判，最终通过真实案例把执行时间从分钟级降至毫秒级。 一、连接算法深度解析 – 优化器的三种武器 当查询涉及多个表时，PostgreSQL 优化器需要在 Nested Loop、Hash Join、Merge Join 中做出选择，并决定连接顺序。这个决策的基础是 基数估计（每步返回的行数）与 代价计算。
SQL 与查询优化（PostgreSQL 篇）· 第二期 窗口函数与 CTE 的深度优化 继第一期掌握执行计划与索引基础后，本期聚焦 SQL 的高级能力：窗口函数（Window Functions） 与 公共表表达式（CTE）。 你将学会如何用它们写出更简洁高效的查询，同时避开常见的性能陷阱——包括 CTE 物化屏障、递归 CTE 的优化技巧，以及窗口函数与索引的协作之道。 一、窗口函数 –
SQL 与查询优化（PostgreSQL 篇）· 第一期 读懂执行计划 & 索引优化入门 本系列专注于 PostgreSQL 中 SQL 能力的深度挖掘与查询性能调优。 第一期从最核心的工具——执行计划入手，结合统计信息与索引选择，带你建立系统性的优化思维。 一、为什么查询优化如此重要？ 很多开发人员写出功能正确的 SQL，却忽略了执行效率。当数据量从万级增长到千万级，一个缺少索引或写法不佳的查询可能导致响应时间从毫秒变成分钟。PostgreSQL 提供了强大的优化器、丰富的索引类型和精准的代价模型，但前提是你要学会如何“引导”它。 优化不是盲目加索引，而是： 看懂执行计划 –