性能瓶颈

数据库自增 ID 方案虽然简单，但在高并发场景下会遇到明显的性能瓶颈。让我们分析这些瓶颈和解决方案。

瓶颈分析

1. 网络延迟

问题：

应用程序 → 数据库（网络往返）
往返时间（RTT）：1-10ms

每次生成 ID 都需要网络调用

影响：

单次延迟：1-10ms
QPS 受限：约 100-1000 QPS
性能下降：明显

示例：

2. 数据库锁竞争

问题：

多个线程同时插入
竞争自增锁
串行化执行

影响：

并发增加 → 锁竞争增加 → 性能下降
100 并发：50,000 QPS
500 并发：10,000 QPS
1000 并发：1,000 QPS

3. 数据库写入压力

问题：

每个 ID 生成都需要写数据库
写入压力巨大
数据库成为瓶颈

影响：

10万 QPS = 每秒 10万次写入
单机 MySQL：约 5万 QPS
需要 2 台数据库实例

4. 连接池耗尽

问题：

高并发下连接池不够
请求等待排队
性能急剧下降

示例：

性能测试

1. 基准测试

测试环境：

数据库：MySQL 8.0
硬件：4核CPU，16GB内存
连接池：20
测试时间：60秒

测试结果：

并发 | QPS     | P50延迟 | P99延迟 | 错误率
-----|---------|---------|---------|--------
10   | 8,500   | 2ms     | 5ms     | 0%
50   | 50,000  | 1ms     | 10ms    | 0%
100  | 50,000  | 2ms     | 20ms    | 0%
500  | 10,000  | 50ms    | 200ms   | 5%
1000 | 1,000   | 500ms   | 1000ms  | 50%

2. 压力测试

结论：

最佳并发：50-100
最大 QPS：50,000
性能拐点：100 并发
崩溃点：1000 并发

优化方案

1. 批量获取

原理： 一次获取一批 ID，本地分配。

实现：

性能提升：

原来：每次请求都访问数据库
现在：1000 次请求才访问数据库一次
性能提升：1000x

2. 双 Buffer 机制

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

性能提升：

零等待：始终有可用 ID
高并发：支持超高并发
性能：接近本地生成

3. 缓存优化

原理： 使用 Redis 缓存 ID 段。

实现：

性能对比

不同方案对比

最佳实践

1. 使用批量获取

2. 使用双 Buffer

3. 使用缓存

总结

数据库自增方案总结

使用建议

推荐使用：

✅ 小型系统
✅ 内部系统
✅ 已有数据库集群
✅ 不想引入新组件

不推荐使用：

❌ 高并发系统
❌ 超大规模系统
❌ 需要极高性能

优化方向

数据库自增 → 批量获取 → 双 Buffer → 其他方案

下一步

了解了数据库自增的性能瓶颈后，我们学习 Redis 方案。

👉 下一章：Redis 方案