1 问题概述
业务数据表e10_common.esch_log为高频DML访问表，日常存在大量INSERT、UPDATE并发操作。该表热点数据长期常驻内存，数据写入、更新时需优先获取内存锁，高并发场景下极易触发锁争用问题，直接导致autovacuum自动清理任务执行失败，死元组持续堆积，最终引发数据库服务器CPU使用率居高不下，严重影响业务运行性能。
2 问题根因分析
- 锁争用严重：表DML操作频繁，大量并发读写需抢占内存缓冲区锁，产生大量锁等待，加剧系统资源消耗。
- 自动清理失效：数据库默认autovacuum参数阈值宽松，无法适配高频更新场景，死元组无法及时回收，持续堆积造成表膨胀。
- 存储碎片过多：表长期高频读写，未做碎片整理，物理存储碎片化严重，放大IO开销与CPU计算开销。
- 内存配置不匹配业务：原有shared_buffers内存参数无法承载高频DML并发场景，内存缓冲区资源不足，进一步加重锁竞争问题。
3 优化整体方案
本次优化采用表碎片重建+内存参数调优+表级精细化自动清理参数配置组合方案，彻底解决锁争用、autovacuum失败、CPU高负载问题，具体分为三步实施：日志表重建清理碎片、数据库共享内存参数调整、表级autovacuum参数精细化配置。
4 详细优化实施步骤
4.1 重建日志表，清理存储碎片与历史垃圾
通过重命名备份原表、新建空白表的方式，彻底清除原有表的存储碎片、死元组，优化表物理存储结构，降低读写开销。该操作需在业务低峰期 或停机窗口执行。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Plain Text -- 1.重命名原日志表，完成数据备份 ALTER TABLE e10_common.esch_log RENAME TO esch_log_bak; -- 2.新建日志表，完全继承原表结构、索引、约束、属性 CREATE TABLE e10_common.esch_log (LIKE e10_common.esch_log_bak INCLUDING ALL); |
4.2 调整数据库内存参数
针对高频DML内存锁争用问题，优化数据库共享缓冲区参数，提升内存承载能力，减少缓冲区锁竞争。物理内存64GB，分配60%给shared_buffers，修改数据库核心配置文件kingbase.conf。
|-------------------------------------------------------|
| Plain Text # 共享缓冲区参数调整，适配高频写入场景 shared_buffers = 38GB |
生效方式：修改配置后重启Kingbase数据库实例生效。
4.3 精细化配置表级Autovacuum参数
保留全局autovacuum_naptime默认1分钟配置（不建议修改全局参数），单独对高频DML的esch_log表收紧自动清理阈值，实现死元组实时、高效回收，避免垃圾数据堆积。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Plain Text -- 定制化配置表级自动清理参数 ALTER TABLE e10_common.esch_log SET ( autovacuum_enabled = on, autovacuum_vacuum_threshold = 50, autovacuum_vacuum_scale_factor = 0.005, autovacuum_analyze_scale_factor = 0.02, autovacuum_vacuum_cost_limit = 10000, autovacuum_vacuum_cost_delay = 1 ); |
4.4 参数详细说明
|---------------------------------|-------|-------------------------------|
| 参数名称 | 配置值 | 参数作用 |
| autovacuum_enabled | on | 强制开启当前表自动清理功能，保障垃圾回收持续生效 |
| autovacuum_vacuum_threshold | 50 | 表死元组达到50行即触发vacuum清理，降低清理触发门槛 |
| autovacuum_vacuum_scale_factor | 0.005 | 表死元组占比达0.5%时触发清理，适配高频更新场景 |
| autovacuum_analyze_scale_factor | 0.02 | 表数据变更占比达2%时自动更新统计信息，优化SQL执行计划 |
| autovacuum_vacuum_cost_limit | 10000 | 提升vacuum单次清理资源上限，加快垃圾数据清理效率 |
| autovacuum_vacuum_cost_delay | 1 | 缩短清理休眠间隔，实现垃圾数据持续实时回收 |
5 优化效果核查SQL
5.1 核查表级autovacuum参数配置是否生效
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Plain Text -- 查看表自定义参数配置 SELECT reloptions FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE n.nspname = 'e10_common' AND c.relname = 'esch_log'; |
5.2 查看表整体统计信息
|-------------------------------------------------------------------------------------------|
| Plain Text -- 查询表读写、垃圾回收统计数据 select * from pg_stat_user_tables where relname='esch_log'; |
5.3 排查长事务与锁阻塞会话
长事务会阻塞autovacuum清理任务，定期排查并处理异常会话，保障垃圾回收正常执行。
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Plain Text -- 查询esch_log表相关活跃长事务、阻塞会话 SELECT pid, now() - query_start AS run_time, state, wait_event_type, wait_event, backend_type, query FROM pg_stat_activity WHERE state = 'active' AND query like '%esch_log%' ORDER BY run_time DESC LIMIT 20; |
6 优化预期效果
- 解决内存锁争用问题，高并发DML场景下锁等待大幅减少；
- autovacuum自动清理任务正常执行，死元组实时回收，彻底解决表膨胀问题；
- 服务器CPU使用率显著下降，数据库运行负载回归正常；
- 清除表存储碎片，有效降低IO开销，提升业务读写并发性能。
7 运维注意事项
- 表重建操作必须在业务低峰期执行，避免业务高峰期产生读写阻塞，备份表esch_log_bak建议留存3-7天，确认业务运行正常后再清理。
- shared_buffers参数修改需要重启数据库实例，操作前需提前规划业务停机窗口，规避业务中断风险。
- 全局参数autovacuum_naptime保持默认1分钟，禁止随意修改，仅通过表级参数适配业务场景，保障全局数据库稳定性。
- 日常运维需定期排查长事务，未提交的长事务会阻断死元组回收，导致优化效果失效。
优化完成后持续监控表死元组数量、autovacuum执行次数、服务器CPU负载，提前预判性能回退风险。