推荐使用Redis的INCR命令实现自增编号，这是最高效的方案。代码示例：redis-cli -h host -p port INCR order_id。这利用了Redis的原子性操作，支持高并发场景，避免了传统数据库的自增ID瓶颈。结合Lua脚本可以进一步优化批量生成：local id = redis.call('INCRBY', KEYS[1], ARGV[1]) return id。

方案一：INCR命令

Redis 自增编号最简单直接的方式就是使用 INCR 命令，INCR 命令会将 key 中储存的数字值增 1。如果 key 不存在，那么 key 的值会先被初始化为 0 ，再执行 INCR 操作：INCR id。INCR 命令是原子的，因此在高并发场景下也能保证 id 唯一且递增。

方案二：INCRBY批量自增

如果需要批量生成自增 id，可以使用 INCRBY 命令，它可以一次性递增指定的步长，比如 INCRBY id 1000 这样就能一次性生成 1000 个连续的自增值，比多次调用 INCR 效率更高，特别适合预分配 id 的场景。

方案三：Lua脚本封装

为了更好地控制自增逻辑，可以使用 Lua 脚本封装，比如生成订单 id 时结合时间戳和自增值：local counter = redis.call('INCR', KEYS[1]) local timestamp = ARGV[1] return timestamp .. string.format('%06d', counter)。这样生成的 id 既有序又唯一，高并发下性能优秀。

方案四：分布式ID生成

在分布式环境中，单机 Redis 可能成为瓶颈，可以用 Redis + 雪花算法结合：雪花算法生成 64 位 ID，利用 Redis INCR 获取序列号部分，确保全局唯一。代码：long workerId = redis.incr('worker:' + machineId) % 32; 然后组装成雪花 ID。

方案五：Hash + INCR组合

有时需要按业务分片自增，可以用 Hash 结构：HINCRBY orders:2023:shop1 total 1。这样每个店铺每天独立自增，避免 key 过多热点问题，适合电商场景。

性能对比与选择

INCR 单机 QPS 可达 10w+，Lua 脚本稍低但更灵活；分布式场景选雪花+Redis。实际选型：小中型项目直接 INCR，大型高并发用 Lua 或分布式方案，避免单点故障用 Redis Cluster。

FAQ
Q: Redis INCR 会不会丢失数据？
A: 单机有 AOF/RDB 持久化，集群用 Sentinel 高可用，几乎不会丢失。
Q: 高并发下 INCR 性能如何？
A: 可支持 10w+ QPS，远超 MySQL 自增。
Q: ID 可以重置吗？
A: 可以用 DEL key 后 INCR 从 1 开始，或用 INCRBY 设置初始值。
Q: Lua 脚本比 INCR 慢吗？
A: 稍慢但原子性更好，单次调用开销微小。