步长策略

步长策略是优化数据库自增 ID 方案的重要方法，让我们深入了解如何通过合理的步长配置提升性能。

步长原理

1. 基本概念

步长（Step）： 每次自增的数值，默认为 1。

示例：

步长 = 1：
1, 2, 3, 4, 5, 6, 7, 8, 9, 10

步长 = 2：
1, 3, 5, 7, 9, 11, 13, 15, 17, 19

步长 = 10：
1, 11, 21, 31, 41, 51, 61, 71, 81, 91

2. 步长的意义

减少数据库写入：

步长 = 1：
每次插入都需要写数据库

步长 = 1000：
可以缓存 1000 个 ID，减少数据库访问

步长配置

1. MySQL 配置

全局配置：

数据设计要点

• 这里关注数据模型和约束关系，不需要记住具体语法。

表级配置：

数据设计要点

• 核心是在 users 里保存业务事实，而不是把规则散落在应用逻辑里。
• 这是一次表结构演进：随着业务能力增加，把新状态、新时间点或新归属关系补进数据模型。
• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 关键字段包括 id、name，它们决定后续查询和管理能力。

会话级配置：

2. PostgreSQL 配置

数据设计要点

• 核心是在 users 里保存业务事实，而不是把规则散落在应用逻辑里。
• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 关键字段包括 id、name，它们决定后续查询和管理能力。

步长策略

1. 固定步长

原理： 使用固定的步长值。

示例：

步长 = 10：
节点 A：1, 11, 21, 31, 41, ...
节点 B：2, 12, 22, 32, 42, ...
节点 C：3, 13, 23, 33, 43, ...
...
节点 J：10, 20, 30, 40, 50, ...

实现：

2. 动态步长

原理： 根据系统负载动态调整步长。

实现：

3. 分层步长

原理： 为不同业务类型设置不同步长。

示例：

用户 ID：步长 1
订单 ID：步长 10
日志 ID：步长 100
消息 ID：步长 1000

实现：

步长优化

1. 批量预取

原理： 一次预取多个 ID，减少数据库访问。

实现：

2. 双 Buffer 机制

原理： 使用两个缓冲区，一个当前使用，一个预加载。

实现：

步长选择

1. 根据业务量选择

低并发（< 1,000 QPS）：步长 1-10
中并发（1,000-10,000 QPS）：步长 10-100
高并发（10,000-100,000 QPS）：步长 100-1000
超高并发（> 100,000 QPS）：步长 1000+

2. 根据可用性选择

单数据库：步长 1
双数据库：步长 2
三数据库：步长 3
N 数据库：步长 N

3. 根据性能选择

性能优先：大步长（1000+）
平衡方案：中等步长（100）
可靠优先：小步长（1-10）

常见问题

1. 步长过大导致 ID 浪费

问题：

步长 = 1000
节点 A：1, 1001, 2001, ...
节点 B：2, 1002, 2002, ...

大量 ID 未使用

解决：

• 合理设置步长
• 定期调整步长
• 监控 ID 使用率

2. 步长过小导致性能差

问题：

步长 = 1
频繁访问数据库
性能下降

解决：

• 增加步长
• 使用批量预取
• 使用双 Buffer

总结

步长策略评价

使用建议

推荐使用：

✅ 固定步长（简单场景）
✅ 批量预取（高并发）
✅ 双 Buffer（超高并发）

不推荐使用：

❌ 步长 1（高并发场景）
❌ 过大步长（资源浪费）

下一步

了解了步长策略后，我们分析数据库自增的性能瓶颈。

👉 下一节：性能瓶颈