活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8c 序列号跳号这事，别按业务单据号去理解

我最近整理 GBase 8c 里自增编号相关问题时，发现序列对象经常被拿来和业务单据号混着讨论。现场一旦看到编号不连续，就有人怀疑事务丢了、主键乱了，甚至开始翻恢复记录。真正落到数据库机制上看，序列本来就不是“连续号码生成器”，它更像一个高并发下快速拿号的数据库对象。

在 GBase 8c 里，序列通常用于主键、流水表 ID、批次 ID 这类技术标识。它的价值是低耦合、高并发、减少热点竞争，而不是保证每个数字都能被业务看见。把序列当成发票号、合同号、财务凭证号来用，后面大概率会被“跳号”问题反复折腾。

## 序列的核心特点

我自己理解下来，序列有三个容易误解的特点。

| 特点 | 现场表现 | 排查时要注意什么 |
| --- | --- | --- |
| 取号独立于事务回滚 | 事务回滚后，已经取过的值不会退回 | 看到空洞不等于数据丢失 |
| cache 会提前分配 | 实例重启或连接异常后，缓存值可能没被使用 | cache 越大，跳号感越明显 |
| 多会话并发取号 | 不同会话拿到的值不按提交顺序呈现 | ID 大小不代表业务提交先后 |

这几个特点放到一起，就能解释很多现场疑问。比如一个批量插入任务失败回滚，序列值已经向前走了；一个应用连接池拿了号但还没插入，连接中断后也会留下空洞；多个业务线程并发提交时，后提交的数据 ID 反而更小，也并不奇怪。

## 先把序列对象查清楚

遇到跳号问题，我通常不会先看应用日志，而是先把对象关系确认清楚。尤其是历史库里，有些表的默认值来自序列，有些表是应用自己拼 ID，还有些表经历过迁移，序列当前值和表内最大值可能已经错开。

```sql
-- 查看当前 schema 下的序列对象
SELECT
    n.nspname AS schema_name,
    c.relname AS sequence_name
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'S'
ORDER BY n.nspname, c.relname;

-- 查看表字段默认值里是否引用序列
SELECT
    n.nspname AS schema_name,
    c.relname AS table_name,
    a.attname AS column_name,
    pg_get_expr(d.adbin, d.adrelid) AS default_expr
FROM pg_attrdef d
JOIN pg_attribute a ON a.attrelid = d.adrelid AND a.attnum = d.adnum
JOIN pg_class c ON c.oid = d.adrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE pg_get_expr(d.adbin, d.adrelid) LIKE '%nextval%'
ORDER BY 1,2,3;
```

这个查询能先回答一个关键问题：到底是谁在用这个序列。现场常见情况是多个表误用了同一个序列，或者测试脚本直接调用 `nextval` 做压测，导致业务表看起来跳得很厉害。

## nextval、currval、setval 的使用边界

序列常用函数不复杂，但用错后影响很大。

| 函数 | 用途 | 我会提醒的风险 |
| --- | --- | --- |
| `nextval` | 获取下一个序列值 | 调用即推进，不随事务回滚 |
| `currval` | 获取当前会话最近一次取到的值 | 当前会话没调用过 `nextval` 时不能拿来当全局当前值 |
| `setval` | 调整序列当前值 | 适合修复迁移后错位，不适合日常频繁调用 |

迁移后最容易遇到的是表里已经有数据，但序列还停留在旧值。表现是新插入数据时报主键冲突。处理思路不是删除数据，也不是让应用重试，而是把序列推进到表内最大值之后。

```sql
-- 示例：订单表迁移后修正序列位置
SELECT setval(
    'ods.order_id_seq',
    (SELECT COALESCE(MAX(order_id), 0) FROM ods.order_base),
    true
);

-- 验证下一次取号
SELECT nextval('ods.order_id_seq');
```

这里第三个参数设为 `true`，表示下一次 `nextval` 返回的是当前值之后的下一个值。现场执行前，我会先确认表上没有并发写入，至少要在维护窗口或应用暂停写入的条件下做。否则刚算完 `MAX(id)`，另一边又插入了新数据，修复动作就可能和业务并发撞上。

## cache 不是越大越好

很多人调序列 cache 是从性能角度出发，这个方向没问题。cache 大一点，可以减少频繁持久化序列状态带来的开销。但 cache 不是单纯的性能参数，它也会影响跳号幅度。

```sql
CREATE SEQUENCE ods.order_id_seq
    START WITH 1
    INCREMENT BY 1
    MINVALUE 1
    NO MAXVALUE
    CACHE 100;
```

我的经验是按对象用途分层设置。

| 使用场景 | cache 倾向 | 说明 |
| --- | --- | --- |
| 技术主键、高频写入事实表 | 可以适当增大 | 更关注吞吐，跳号可接受 |
| 低频字典表、配置表 | 保守设置 | 性能压力小，没必要放大空洞 |
| 对外展示编号 | 不建议直接用序列 | 应该另做业务编号规则 |
| 财务、合同、审计类单据 | 不建议用普通序列保证连续 | 连续性应由业务流程和号段表控制 |

如果业务方只是要求“唯一”，序列很合适。如果业务方要求“连续、可解释、可追溯、按日期重置”，那就已经超出普通序列的边界了。

## 分布式环境里更不能拿 ID 当时间线

GBase 8c 支持分布式部署，序列在这种环境下更容易被误读。应用从 CN 连接，数据落到不同 DN，多个会话并发写入时，ID 的增长顺序和事务提交顺序、业务发生顺序并不完全一致。

我在现场一般会明确三条开发规范。

| 规范 | 原因 | 推荐做法 |
| --- | --- | --- |
| 不用 ID 判断业务先后 | 并发提交会打乱可见顺序 | 用业务时间、提交时间、状态流转时间 |
| 不用 ID 判断是否漏数 | 序列天然可能跳号 | 用行数、校验表、业务状态核对 |
| 不直接暴露技术 ID | 用户容易把空洞理解成异常 | 对外编号单独生成 |

比如订单列表排序，如果直接 `ORDER BY order_id DESC`，看起来简单，但在并发写入和补录数据场景下并不严谨。我更倾向于使用业务创建时间，再用 ID 做次级排序。

```sql
SELECT order_id, order_no, create_time, order_status
FROM ods.order_base
WHERE customer_id = 'C20260514001'
ORDER BY create_time DESC, order_id DESC
LIMIT 50;
```

## 对外连续编号可以用号段表

如果确实要做业务连续号，我更倾向于把它从序列里拆出来，做成业务号段或编号服务。数据库里可以用一张号段表记录业务维度、日期、当前值，由应用在事务中加锁更新。

```sql
CREATE TABLE biz_no_segment (
    biz_type       varchar(32) PRIMARY KEY,
    current_value  bigint NOT NULL,
    updated_at     timestamp NOT NULL DEFAULT current_timestamp
);

-- 取号时锁定对应业务类型
BEGIN;

SELECT current_value
FROM biz_no_segment
WHERE biz_type = 'CONTRACT_202605'
FOR UPDATE;

UPDATE biz_no_segment
SET current_value = current_value + 1,
    updated_at = current_timestamp
WHERE biz_type = 'CONTRACT_202605';

COMMIT;
```

这种方式吞吐不如序列，但它满足的是另一类目标：可控、可解释、能按业务维度管理。真正落到现场时，技术主键和业务编号分离，后续沟通成本会低很多。

## 跳号问题的排查清单

| 排查项 | SQL 或动作 | 目的 |
| --- | --- | --- |
| 查表内最大 ID | `SELECT MAX(id) FROM table_name;` | 判断序列是否落后 |
| 查默认值来源 | 查询 `pg_attrdef` | 确认字段是否使用序列 |
| 查调用方 | 应用 SQL、作业脚本、存储过程 | 找出额外 `nextval` 调用 |
| 查 cache 设置 | 查看序列定义 | 判断跳号幅度是否和 cache 相关 |
| 查批处理失败记录 | 作业日志、事务回滚记录 | 判断是否大量取号未提交 |

我不太建议把跳号问题包装成数据库异常。更稳妥的做法是先确认它是不是机制内现象，再判断是否影响业务语义。如果只是技术主键跳号，通常不需要修。如果业务把序列当成了连续单据号，就要调整设计边界。

## 参考资料

```text
GBase 8c 文档介绍 https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/
GBase 8c SQL参考指南 https://www.gbase.cn/docs/gbase-8c/05%20SQL%E5%8F%82%E8%80%83/SQL%E8%AF%AD%E6%B3%95
GBase 8c 开发者指南 系统模式 https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E7%B3%BB%E7%BB%9F%E6%A8%A1%E5%BC%8F
```





GBase 8c

GBase 8c 序列号跳号这事，别按业务单据号去理解

GBase 8c 序列号跳号这事，别按业务单据号去理解

评论

热门帖子