# 金仓 KES V9R2C16：64 位事务号不是修 Bug，是把 freeze 从改成「闹钟」

---

## 00 / 先说任务，再说结论

**体验 64 位事务 ID，核对 VACUUM/Autovacuum 相关参数变化，验证数据库长期运行余量。**

我的打法很简单：不跑分、不背书，只验三件事——

1. 参数是不是**真**从 integer 升到 int64 了（不是改个说明文档糊弄人）；
2. 默认值到底跳了多少；
3. 长事务这个老命门，现在是什么状态。

**先给结论：落地了，而且是全链路落地。** 另外我抓到一个有意思的细节——活动页口径和实测值对不上号，后面细说。

---

## 01 / 登录，验明正身

```bash
[kingbase@openeuler-server ~]$ ksql -U system -W -d test -p 54322
口令：
授权类型: 标准版.
输入 "help" 来获取帮助信息.

test=#
```

![登录 KingbaseES](https://developer.qcloudimg.com/http-save/yehe-11546919/35406eaf52bb96552b84b22d6438f09e.png)

升级之后第一件事不是跑分，是**验明正身**——先确认你跑的真是 64 位那一版。一条命令就够：

```sql
SHOW autovacuum_freeze_max_age;
```

```language
test=# SHOW autovacuum_freeze_max_age;
 autovacuum_freeze_max_age 
---------------------------
 10000000000
(1 行记录)

test=#
```

![SHOW autovacuum_freeze_max_age](https://developer.qcloudimg.com/http-save/yehe-11546919/f2fa35e512e854d8c8a53ac745117a07.png)

**10000000000，100 亿。** 这个值一出来，基本就确认 64 位生效了——老版本（PG 系默认）这个参数是 2 亿，差着 50 倍。

### 这里有个口径要较真一下

活动页的口径写的是「autovacuum_freeze_max_age 默认值由 **4 亿**提升至 **200 亿**」。但我实测 SHOW 出来是 **100 亿**。

对照《KingbaseES V9 版本说明书》核对之后，事情清楚了：

| 参数 | 变更前（integer） | V9R2C16（int64） | 倍数 |
|------|------------------|------------------|------|
| `autovacuum_freeze_max_age` | 默认 **2 亿** | **100 亿** | 50 倍 |
| `autovacuum_multixact_freeze_max_age` | 默认 **4 亿** | **200 亿** | 50 倍 |

**活动页说的「4 亿→200 亿」，其实是 multixact 那个参数。** 两个参数都是 50 倍，方向没错，但口径对错了行。这里不吹不黑记录一笔：**以 SHOW 出来的为准。**

---

## 02 / 六个 freeze 参数，全量核对

光看一个参数不算核对，把全家桶拉出来看：

```sql
SELECT name, vartype, setting
FROM sys_settings
WHERE name LIKE '%freeze%';
```

```language
test=# SELECT name, vartype, setting
test-# FROM sys_settings
test-# WHERE name LIKE '%freeze%';
                name                 | vartype |   setting   
-------------------------------------+---------+-------------
 autovacuum_freeze_max_age           | int64   | 10000000000
 autovacuum_multixact_freeze_max_age | int64   | 20000000000
 vacuum_freeze_min_age               | int64   | 50000000
 vacuum_freeze_table_age             | int64   | 150000000
 vacuum_multixact_freeze_min_age     | int64   | 5000000
 vacuum_multixact_freeze_table_age   | int64   | 150000000
(6 行记录)

test=#
```

![六个 freeze 参数全部 int64](https://developer.qcloudimg.com/http-save/yehe-11546919/2f5d44982c7bb2f6ae2ef5ad5b75d568.png)

六行，**vartype 一列清一色 int64**。注意这不是「把默认值改大」那么简单——类型从 integer 升到 int64，意味着整个回收策略的时间尺度往上抬了一个数量级，而不是在旧尺度上修修补补。

顺带说一句：`vacuum_freeze_min_age` 实测是 5000 万、`vacuum_freeze_table_age` 是 1.5 亿，这两个是「多老的事务才顺手冻结」「多老的表才整表冻结」的日常档位，保持温和是合理的——真正放开的，是那条「逼你大动干戈」的红线。

---

## 03 / 一个彩蛋：age 等于 2^63-1 是怎么回事

核对参数的时候我顺手扫了一眼表级事务年龄，结果看到一个非常吓人的数字：

```sql
SELECT c.oid::regclass AS relname,
       age(c.relfrozenxid) AS age
FROM sys_class c
WHERE c.relkind IN ('r', 'm') 
  AND age(c.relfrozenxid) > 0
ORDER BY age DESC LIMIT 3;
```

```language
test=# SELECT c.oid::regclass AS relname,
test-#        age(c.relfrozenxid) AS age
test-# FROM sys_class c
test-# WHERE c.relkind IN ('r', 'm') 
test-#   AND age(c.relfrozenxid) > 0
test-# ORDER BY age DESC LIMIT 3;
      relname      |         age         
-------------------+---------------------
 _kingbase_loginfo | 9223372036854775807
 _att              |                  32
 _typ              |                  32
(3 行记录)

test=#
```

![表级 age 出现 2^63-1](https://developer.qcloudimg.com/http-save/yehe-11546919/2d8415f8594b075343e34b6f9eeda1b5.png)

`9223372036854775807`——正好是 **2^63 - 1**，int64 的天花板。第一眼看到我也愣了一下：这库刚装好，哪来这么老的事务？

后来想明白了：这是 `relfrozenxid` **无效时的特殊标记值**（比如不产生事务号的系统表/日志表），不是真实年龄。PG 老玩家看到这个数会心头一紧，赶紧写进这篇文章里——**先替你踩了这颗惊吓，看到 92 亿亿别慌，它是个哨兵值，不是事故。**

---

## 04 / 余量怎么算：100 亿到底是多少天

空口说「余量很大」没意思，算一笔账。先看各库当前水位：

```sql
SELECT datname,
       age(datfrozenxid) AS xid_age,
       pg_size_pretty(pg_database_size(datname)) AS sz
FROM sys_database
ORDER BY xid_age DESC;
```

```language
test=# SELECT datname,
test-#        age(datfrozenxid) AS xid_age,
test-#        pg_size_pretty(pg_database_size(datname)) AS sz
test-# FROM sys_database
test-# ORDER BY xid_age DESC;
  datname  | xid_age |   sz   
-----------+---------+--------
 test      |      41 | 373 MB
 kingbase  |      41 | 16 MB
 template1 |      41 | 16 MB
 template0 |      41 | 16 MB
 security  |      41 | 16 MB
(5 行记录)

test=#
```

![各库事务年龄水位](https://developer.qcloudimg.com/http-save/yehe-11546919/85f5c5f5999838a25e6e90d76a48ea58.png)

然后按不同持续 TPS 把两个关键尺度都算出来（算式透明，欢迎复核）：

- **100 亿阈值**（autovacuum 主动出击的闹钟）：`10^10 ÷ TPS` 秒
- **2^63-1 硬上限**（真正拒绝写入的死线）：`9.22×10^18 ÷ TPS` 秒

| 持续 TPS | 100 亿阈值多久触顶 | 2^63-1 上限多久见底 |
|---------:|-------------------|---------------------|
| 10 | ≈ 31.7 年 | ≈ 292 亿年（宇宙年龄的两倍） |
| 1,000 | ≈ 116 天 | ≈ 2.9 亿年 |
| 10,000 | ≈ 11.6 天 | ≈ 2,900 万年 |
| 50,000 | ≈ 2.3 天 | ≈ 584 万年 |

看出门道了吗？**100 亿这个闹钟在高位 TPS 下照样会响**（1 万 TPS 十来天就触顶一次），但它已经不是死线了——32 位时代触顶意味着「半夜爬起来救火甚至停机」，现在它只是 autovacuum 该干活的一声铃。

**真正的死线 2^63-1，远到失去工程意义。**

一句话总结这次体验的核心：**64 位事务号的价值不是「你不用 freeze 了」——死元组不会因为计数器变大就自己消失；它的价值是 freeze 从死刑变成了闹钟。你终于敢开长事务了，而这恰好是 Agent 时代最稀缺的自由度。**

---

## 05 / 实操 A｜把长事务「钉」在屏幕上

验完参数，验行为。长事务是事务号回收链路的头号杀手，这套动作我闭着眼都能敲完，你跟着走一遍就懂了。

**① 复现：开一条不提交的事务（模拟 Agent 会话挂住）**

```sql
BEGIN;
SELECT count(*) FROM agent_log;
-- 就挂在这儿，不 COMMIT
```

```language
test=# BEGIN;
BEGIN
test=# SELECT count(*) FROM agent_log;
  count  
---------
 1000000
(1 行记录)

test=#
```

![开一条不提交的事务](https://developer.qcloudimg.com/http-save/yehe-11546919/7289820cb53bacb443374a2690fb432c.png)

**② 揪出它：锁侦探日常第一件事**

```sql
SELECT pid, state,
       now() - xact_start AS duration,
       left(query, 60) AS sql_head
FROM sys_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY duration DESC LIMIT 5;
```

```language
test=# SELECT pid, state,
test-#        now() - xact_start AS duration,
test-#        left(query, 60) AS sql_head
test-# FROM sys_stat_activity
test-# WHERE xact_start IS NOT NULL
test-# ORDER BY duration DESC LIMIT 5;
   pid   | state  |           duration            |                sql_head                
---------+--------+-------------------------------+----------------------------------------
 3627377 | active | +000000000 00:00:00.000000000 | SELECT pid, state,                    +
         |        |                               |        now() - xact_start AS duration,+
         |        |                               |   
(1 行记录)

test=#
```

![sys_stat_activity 揪长事务](https://developer.qcloudimg.com/http-save/yehe-11546919/6f62be37adb6db8274e44f3fc44bb1e6.png)

> 示意判断标准：看到 `idle in transaction` 且事务年龄是分钟级，不用再查了，就是它。

**③ 处置：先礼后兵**

```sql
-- 温柔：只掐掉当前语句，连接还留着（先试这个）
SELECT sys_cancel_backend(8821);

-- 强硬：直接把连接踢了
SELECT sys_terminate_backend(8821);
```

⚠️ 动手之前先确认它不是核心业务的批处理。我真见过有人杀掉了对账任务，第二天财务找上门——那场面，比 OOM 还难看。

**④ 防复发：把「超时」这件事交给数据库自己管**

```sql
ALTER SYSTEM SET idle_in_transaction_session_timeout = '60s';
ALTER SYSTEM SET statement_timeout = '30s';
SELECT sys_reload_conf();
```

```language
test=# ALTER SYSTEM SET idle_in_transaction_session_timeout = '60s';
ALTER SYSTEM
test=# ALTER SYSTEM SET statement_timeout = '30s';
ALTER SYSTEM
test=# SELECT sys_reload_conf();
 sys_reload_conf 
-----------------
 t
(1 行记录)

test=#
```

![超时参数全局生效](https://developer.qcloudimg.com/http-save/yehe-11546919/8fad808c8e67450d62486daee3264806.png)

> 一句话总结：**能靠参数解决的，别靠值班的人。** 人会上厕所，参数不会。

---

## 06 / 实操 B｜把事务号水位，做成一条能盯的监控线

```sql
SELECT datname,
       age(datfrozenxid) AS xid_age,
       current_setting('autovacuum_freeze_max_age')::bigint AS warn_line,
       round(age(datfrozenxid)::numeric
             / current_setting('autovacuum_freeze_max_age')::bigint * 100, 3) AS pct
FROM sys_database ORDER BY xid_age DESC;
```

```language
test=# SELECT datname,
test-#        age(datfrozenxid) AS xid_age,
test-#        current_setting('autovacuum_freeze_max_age')::bigint AS warn_line,
test-#        round(age(datfrozenxid)::numeric
test-#              / current_setting('autovacuum_freeze_max_age')::bigint * 100, 3) AS pct
test-# FROM sys_database ORDER BY xid_age DESC;
  datname  | xid_age |  warn_line  |  pct  
-----------+---------+-------------+-------
 test      |      45 | 10000000000 | 0.000
 kingbase  |      45 | 10000000000 | 0.000
 template1 |      45 | 10000000000 | 0.000
 template0 |      45 | 10000000000 | 0.000
 security  |      45 | 10000000000 | 0.000
(5 行记录)

test=#
```

![水位监控线：离红线还有多远](https://developer.qcloudimg.com/http-save/yehe-11546919/566dc6ef567f7e3bdeb2211c9fa2aa09.png)

`pct` 这一列就是我说的「离红线还有多远」。现在它憋了半天憋出个 0.000——挺好，**监控线存在的意义不是天天报警，是让你敢把报警阈值设得心安理得。**

---

## 07 / 两条收尾建议（自动清理方向）

1. **升级后立即做一轮 `VACUUM FREEZE`**：把存量事务年龄压到新尺度的起点上，别让老账带进新账本。命令不复杂，但要在业务低峰跑：

   ```sql
   VACUUM (FREEZE, VERBOSE) 你的核心大表;
   ```

2. **freeze 相关参数不建议一上来就调**：默认值已经放到 100 亿/200 亿，先把监控线（实操 B 那条 SQL）挂上，观察一两个周期再动。**能靠默认值解决的，别靠手艺。**

---

## 08 / 结论

这次体验官任务，三件事都验完了：

- ✅ **参数真升级了**：6 个 freeze 参数 vartype 全部 int64，不是文档话术；
- ✅ **默认值真跳了**：`autovacuum_freeze_max_age` 2 亿 → 100 亿，`autovacuum_multixact_freeze_max_age` 4 亿 → 200 亿，都是 50 倍（活动页口径把这两个参数写串了行，以实测为准）；
- ✅ **余量真够用**：硬上限 2^63-1 在任何现实 TPS 下都远到没有工程意义，freeze 从「死刑」降级成「闹钟」。


---

> **关于作者**：马顺华（shunwah），江湖人称「数据库界华少」。墨天轮 MVP · 崖山 YVP · KaiwuDB MVP · 金仓 KVA · TiDB MVA · OpenTenBase ACE。
> **利益声明**：本文为金仓数据库体验官活动（DBA 体验方向）参与内容，作者为金仓 KVA（社区大使），观点仅代表个人，与厂商立场无关。所有实测数据均来自 openEuler 22.03 LTS-SP4 + KingbaseES V009R002C016 个人测试环境，可复现。


体验 64 位事务 ID，核对 VACUUM/Autovacuum 相关参数变化，验证数据库长期运行余量。

实测金仓 KES V9R2C16：64 位事务号不是修 Bug

实测金仓 KES V9R2C16：64 位事务号不是修 Bug，是把 freeze 改成「闹钟」

运维工程师

人工智能

金仓KES V9R2C16实现64位事务号全链路落地，6个freeze参数类型全部升级为int64，默认值提升50倍至100亿/200亿。freeze机制从"死刑"变为"闹钟"，2^63-1硬上限让长事务不再受限。实测数据与活动页口径存在差异，以实际SHOW结果为准。

代码解释

数据库

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

实测金仓 KES V9R2C16：64 位事务号不是修 Bug-腾讯云开发者社区-腾讯云

实测金仓 KES V9R2C16：64 位事务号不是修 Bug

实测金仓 KES V9R2C16：64 位事务号不是修 Bug

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐