# 缓存命中率 99.99%、死锁为 0 的金仓库，藏着三处出厂默认配置的雷

> **架构与运维踩坑实录**
> 作者：（数据库界华少）｜公众号「shunwah星辰数智社」

前阵子接手一个金仓库做例行巡检，第一眼数据漂亮得我想直接交差：缓存命中率 99.99%，死锁 0，锁等待 0，回滚率 0.059%，WAL 归档 216 个零失败。这库跑了一阵子没出过大事，怎么看怎么是个模范生。

结果我手贱多扒了一层配置。好家伙，三处出厂默认配置，照搬生产就是埋雷。

这篇把巡检思路、查到的三颗雷、顺手收拾的两个小毛病，连同一个我自己看错的结论，原原本本捋一遍。所有数字来自这一个实例（KingbaseES V009R003C018，底层 PG 12.1），不通用，换你的库请以自己查出来的为准。

---

## 一、先看数据：漂亮得我想直接交差

巡检脚本跑完，看板长这样：

| 指标 | 实测值 |
|---|---|
| 缓存命中率 | **99.99%** |
| 死锁 | **0** |
| 锁等待 | **0** |
| 回滚率 | **0.059%** |
| WAL 归档 | **216 个，0 失败** |
| 强制检查点占比 | **0.04%** |

最后一行值得多说一句。强制检查点占比低，说明 `max_wal_size` 给得够，WAL 写压力不大，这是好事。六项全绿，交差完全说得过去。

但我在这个行业待久了有个习惯：**看板越干净，越要往下翻一层。** 因为看板反映的是"跑起来之后没出事"，反映不了"出事之后你能不能查"。

往下翻，就翻出三颗雷。

---

## 二、雷一：慢查询采集，装了但没开

我想看 TOP SQL，习惯性查统计视图：

```sql
SELECT * FROM sys_stat_statements;
```

返回 **0 行**。

第一反应是扩展没装。查了一圈，扩展装了（版本 1.11），也预加载了，唯独一个参数关着：

```sql
SHOW sys_stat_statements.track;
-- none
```

`track = none`，等于表建好了、数据一条不记。这就是为什么查不到 TOP SQL。跟你开不开 `log_min_duration_statement` 是两码事，那个是日志，这个是内存里的统计视图。

**坑中坑**：金仓的慢查询视图叫 `sys_stat_statements`，不是 PG 原版的 `pg_stat_statements`；时间字段叫 `total_exec_time`，不是 `total_time`。名字改过，照 PG 的写法直接扑空。我第一条查询就是照着 PG 写的，查了个寂寞。

修复，`sighup` 级别，不用重启：

```sql
ALTER SYSTEM SET sys_stat_statements.track = 'top';
SELECT sys_reload_conf();

ALTER SYSTEM SET log_min_duration_statement = '2s';
SELECT sys_reload_conf();
```

---

## 三、雷二：三个超时，全裸奔

这一颗最要命。三个参数，出厂默认全是"不设防"：

| 参数 | 当前值 | 后果 |
|---|---|---|
| `statement_timeout` | **0** | 一条烂 SQL 能拖死全库，永不超时 |
| `idle_in_transaction_session_timeout` | **0** | 空闲事务永不超时，长事务堆积 |
| `log_min_duration_statement` | **-1** | 无慢 SQL 日志，事后追不了 |

`statement_timeout = 0` 是生产血案常客。那句"一条 SQL 跑了三天"，十有八九栽在这。它后面排队的会话全都得陪着，连接池慢慢占满，最后业务侧看到的现象是"系统卡死"。

`idle_in_transaction_session_timeout = 0` 更阴。事务开着不干活，行锁就一直攥在手里。我前面那篇写锁事故的稿子里，一个挂了三个小时的事务堵了二十多个会话，根子就在这。当时杀了人还得熬四十分钟排查，如果有这个参数，根本不会走到那一步。

修复注意，这两个都是 `postmaster` 级：

```sql
ALTER SYSTEM SET statement_timeout = '30min';
ALTER SYSTEM SET idle_in_transaction_session_timeout = '10min';
SELECT sys_reload_conf();
```

`sys_reload_conf()` 能热加载一部分，但 `statement_timeout` 这类建议安排重启窗口确保全量生效。具体超时值没有标准答案，我给的是示例，你得按自己的批处理时长定。定短了杀正常任务，定长了等于没设。

---

## 四、雷三：该开的日志开关，一个没开

| 参数 | 当前 | 建议 |
|---|---|---|
| `log_lock_waits` | off | on，锁等待才看得见 |
| `log_checkpoints` | off | on，检查点耗时可追溯 |
| `track_io_timing` | off | on，IO 瓶颈有数据 |
| `temp_file_limit` | -1 | 设上限，大排序别吃满磁盘 |

这四个不致命，但加起来决定了出事那一晚你是"有据可查"还是"两眼一抹黑"。

`log_lock_waits` 我单独说。锁等待这个事，发生时你在现场也未必抓得到，事后想复盘只能翻日志。这个开关关着，等于把最重要的排障线索自己剪了。一颗雷二里那个挂了三小时的事务，如果当时开了 `log_lock_waits`，日志里会直接写清楚"会话 X 等锁超过 deadlock_timeout"，值班的人照着 pid 去查就行，不用我从头捋。

---

## 五、顺手收拾的两个小毛病

### 1. `users` 和 `products` 从没 analyze 过

`last_analyze` 是 NULL。优化器拿不到行数，计划选择就是拍脑袋。数据量小时看不出来，表一涨，该走索引的走了全表，你排查半天发现是统计信息过期。

```sql
ANALYZE users, products;
```

### 2. 三个索引两个月零扫描

`idx_orders_user_id`、`idx_order_items_product_id`，还有 `idx_order_items_order_id`（跟已有的 `UNIQUE(order_id, product_id)` 前缀重复）。

删索引我**只给了注释没执行**。`idx_order_items_product_id` 对应外键，父表删除时要扫子表，删了可能让删操作变慢。演示库随意，生产建议先留着观察一轮再说。

**这里踩我自己一脚。** 我最早看索引的时候跟人说"这库没外键"，后来查 `pg_constraint` 才发现，`order_items` 上有 2 个外键，`orders` 上 1 个，主键、唯一键、CHECK 约束（金额≥0、数量>0、status 枚举）一样不缺。只看索引不看约束，结论能给反。所以我现在的规矩是：说"没有"之前，先查一遍再说"有"。

---

## 六、金仓给我上的三堂课

写巡检脚本连库的时候，踩了三个坑，全是 MySQL 兼容模式埋的。

**第一堂，`||` 在金仓里是逻辑 OR，不是字符串拼接。** 我写 `nsp||'.'||tbl` 想拼表名，报 `pg_relation_size(boolean) 不存在`。表名全变成了 boolean。拼接得用 `concat()`。

**第二堂，ksycopg2 的 URI 不做百分号解码。** 密码里的 `^` 我按惯例编码成 `%5E`，结果反而认证失败，原样写才过。这个坑特殊字符密码的同学会反复栽。

**第三堂，`FILTER`、`\s` 正则、`extract(epoch FROM interval)` 都不支持。** 脚本得绕写法。

这些不是 Bug，是金仓的脾气。记下来，下次少踩。

---

## 七、修复清单

全套参数修复加 ANALYZE 加索引建议，我打成了一个 SQL 文件，每项标了生效方式（`postmaster` 重启 / `sighup` 热加载）。**脚本我只生成没执行**，改生产参数得你点头，尤其 `statement_timeout` 这类一刀下去会杀会话的。

按生效方式分三档，执行前对着看一眼：

| 生效方式 | 参数 | 动作 |
|---|---|---|
| sighup 热加载 | `sys_stat_statements.track`、`log_min_duration_statement` | 改完 `sys_reload_conf()` 即生效 |
| postmaster 重启 | `statement_timeout`、`idle_in_transaction_session_timeout` | 安排窗口重启 |
| 需评估 | `temp_file_limit`、删索引 | 先看一轮再动 |

---

## 八、说点掏心窝子的

出厂默认值是给 Demo 用的，不是给生产用的。

巡检真正看的不是"它健不健康"，是"它在哪裸奔"。那个 99.99% 缓存命中再好看，三个超时一裸奔，生产环境随时教你做人。看板全绿只代表过去没出事，不代表出事时你有证据。

我现在的习惯是，每次接手新库，先花半小时把这批参数扒一遍。慢查询开没开，超时设没设，日志开关在不在。半小时换一个安稳，这笔账怎么算都划算。

---

> **关于我**：江湖人称数据库界华少，一个在分布式库里反复渡劫的 DBA。运营公众号「shunwah星辰数智社」，解锁 OceanBase、MySQL、OpenGauss、金仓、崖山、KaiwuDB、TiDB 等十几家数据库官方认证。
>
> 原创内容，转载请联系授权。


前阵子接手一个金仓库做例行巡检，第一眼数据漂亮得我想直接交差：缓存命中率 99.99%，死锁 0，锁等待 0，回滚率 0.059%，WAL 归档 216 个零失败。这库跑了一阵子没出过大事，怎么看怎么是个模范生。

缓存命中率 99.99%、死锁为 0  藏着三处雷

前阵子数据库做例行巡检，第一眼数据漂亮得想直接交差：缓存命中率 99.99%，死锁 0，锁等待 0，WAL 归档 216 个零失败。结果多扒了一层配置，查出三处出厂默认配置，照搬生产就是埋雷。

运维工程师

数据库

运维

后端

金仓库巡检看似全绿，实则三处出厂默认配置埋雷：慢查询采集未开启、三个超时参数裸奔、日志开关缺失。文中详解修复方案与运维踩坑实录，附完整参数调优清单，助你避免生产环境事故。

代码解释

MySQL

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

缓存命中率 99.99%、死锁为 0  藏着三处雷-腾讯云开发者社区-腾讯云

缓存命中率 99.99%、死锁为 0 藏着三处雷

缓存命中率 99.99%、死锁为 0 藏着三处雷

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐