KingbaseES LWLock buffer_mapping 等待

在KingbaseES数据库中，会话在将数据块与共享缓冲池的缓冲区相关联时，会触发“LWLock buffer_mapping”等待事件。
这类事件涉及到一种轻量级锁（lwlock），类似于Oracle中的闩锁。这个锁在不同的数据库中可能有不同的名称，但通常被称为buffer_mapping或BufMappingLock。它主要用于实现对HASH BUCKET的有序访问。在KingbaseES，为了降低多个后端进程间的访问冲突，采用了分区锁机制，将整个HASH TABLE分成多个部分（默认为128个，具体数目视版本而定），每个部分配备一个lwlock。当多个后端进程访问缓冲区时，它们首先计算HASH值以确定HASH TABLE的位置，然后获取相应的 BufMappingLock，以便进一步访问HASH TABLE、查找HASH CHAIN，并最终定位到特定的BUFFER。如果两个后端进程访问的BUFFER位于不同的分区锁范围内，则不会发生冲突；如果位于相同分区，则可能产生冲突。

“LWLock:buffer_mapping”等待事件在KingbaseESV8R6数据库中发生于以下几种场景：

• 当进程在缓冲区表中搜索页面，并尝试获取共享缓冲区映射锁时。
• 当进程需要将页面加载到缓冲池中，并因此获取独占缓冲区映射锁时。
• 当进程从缓冲池中删除页面，并获取独占缓冲区映射锁时。

这些场景反映了数据库在处理缓冲区访问和管理时的不同操作需求，其中锁的获取是为了确保数据的一致性和完整性。

当“buffer_mapping”等待事件数异常增高时，可能的原因包括：

• 执行大型长时间查询。
• 索引和表的膨胀。
• 进行全表扫描。
• 共享缓冲池大小不足。

要解决“LWLock:buffer_mapping”等待事件，可以采取以下措施：

评估索引策略：确保索引和表没有过度膨胀，这可能导致不必要的页面读取。对于含有冗余行的表，考虑数据归档和删除无用行，然后重建索引。这通常比在维护索引的同时清理表更高效。

优化常用查询的索引：检查sys_stat_database中的tup_returned和tup_fetched指标，确认索引是否能够有效支持查询。如果读取的行数明显高于返回给客户端的行数，可能需要优化索引。

减少缓冲区需求：通过实施小批量操作或对大表进行分区，降低对缓冲区的需求。

增加共享缓冲区大小：如果有足够的内存，可以考虑增加shared_buffers参数的值，这有助于减少等待事件。

通过这些方法，可以有效减少LWLock:buffer_mapping等待事件的发生，提升数据库性能。