热点块问题源于高并发下对同一数据页的集中访问，导致缓冲区争用和锁竞争。常见于自增主键插入、频繁读取配置表、索引设计不合理等场景。可通过pg_stat_statements、pg_locks、pg_buffercache等视图识别热点。优化策略包括：使用UUID或哈希分区分散写入；增大序列cache减少争用；启用hot update和调整fillfactor减少页分裂；应用层缓存频繁读取的小表；批量处理降低访问频次。配置上可调大shared_buffers、设置effective_cache_size、启用并行扫描缓解buffer压力。关键在于分散访问、减少集中I/O与锁冲突，需结合业务与SQL模式持续监控调优。
PostgreSQL 中的“热点块”（Hot Block）通常指被频繁访问的数据块，可能引发严重的锁竞争或缓冲区争用，导致性能下降。这类问题常见于高并发场景下对同一行、同一索引页或表页的集中访问。解决热点块问题需要从查询、索引、表结构和配置等多方面入手。
理解热点块的成因
热点块的本质是大量并发进程集中在少数几个数据页上操作，主要出现在：
- 频繁更新或插入同一主键/索引值（如自增 ID 的尾部插入）
- 高并发读取同一配置表或状态记录
- 索引设计不合理导致所有查询都命中同一个索引页
- 序列（sequence）争用导致 nextval 成为瓶颈
当多个后端进程反复访问相同的 buffer，会导致 BufferPin 激烈竞争，甚至出现 IO 等待或 LWLock 争用。
识别热点块的方法
通过系统视图可以定位热点：
- pg_stat_statements：查看高频执行的 SQL
- pg_locks：观察是否存在长时间持有的行锁或页锁
- pg_buffercache（需加载模块）：查看哪些数据块在 shared buffers 中占比高且访问频繁
- perf 或 pg_profile 工具：分析进程等待集中在哪个函数或 buffer 类型
例如，使用以下语句查看最常驻缓存的数据块：
SELECT c.relname, b.forktype, b.blocknumber, count(*) AS usage_count FROM pg_buffercache b JOIN pg_class c ON b.relfilenode = c.relfilenode WHERE c.relname = 'your_table_name' GROUP BY c.relname, b.forktype, b.blocknumber ORDER BY usage_count DESC LIMIT 10;减少热点块的优化策略
针对不同类型的热点，可采取如下措施：
1. 分散写入负载- 避免单点插入：使用 UUID 替代 serial 主键，或采用哈希分片方式分布写入位置
- 使用 hash 分区表 将数据打散到多个子表中，降低单个表页压力
- 调整索引类型：考虑使用 BRIN 索引 替代 B-tree（适用于时序数据）
- 增加序列的 cache 值（如 CACHE 100），减少对 sequence tuple 的争用
- 避免在高并发事务中频繁调用 nextval()
- 考虑使用多序列轮询机制分散生成器压力
- 启用 hot update（Heap Only Tuples）减少索引页修改频率
- 合理设置 fillfactor（如 fillfactor=70）预留空间，减少页分裂
- 避免长事务和大事务，及时提交以释放 buffer 和锁
- 将频繁读取的小表移至应用缓存（Redis、Memcached）
- 使用 UNLOGGED 表 存储临时中间结果，减少 WAL 和刷脏压力
- 批量处理代替逐条更新，降低 buffer 访问频次
调整 PostgreSQL 配置缓解争用
适当调优底层参数有助于减轻 buffer 竞争：
- shared_buffers：增大共享缓冲区可提升缓存命中率，但不宜超过物理内存的 1/4
- effective_cache_size：告知查询规划器可用的总缓存能力，影响执行计划选择
- max_parallel_workers_per_gather：利用并行扫描分散 buffer 访问压力
- checkpoint_segments / checkpoint_timeout：平滑检查点 I/O，避免集中刷脏加剧热点
基本上就这些。热点块问题不是单一层面的问题，必须结合业务特点、SQL 模式和系统监控综合判断。关键在于减少对同一物理存储位置的集中访问，通过分散、缓存、异步等方式解耦高并发压力。定期审查执行计划和 buffer 使用情况，能帮助提前发现潜在热点。不复杂但容易忽略。
