@jdz 你的描述很模糊，id=3 这行存在？

id 是唯一索引的时候没有使用 next_key locking，应该是 record lock

另外为什么还在用 MyISAM 引擎可以说下理由？

可以给出具体代码和环境吗

@kayseen 这个 base62 可以被反解，你的业务是需要能被反解还是不能被反解的？这套方案主要解决了分布式发唯一号的坑，不过可以反推原来序号这个问题可能还需要额外解决，因为 base62 出来之后不是个随机数，其实应该说是 62 进制的顺序增长的数比较合适

@kayseen 我的思路就是你只要能够保证分发的数字（ deci ）唯一，就能保证 base62 没有冲突，分发唯一这个靠 ZK 和本地库的自增使用来保证，或者自己想思路也可以

@kayseen 不好意思 排版有点问题，下面这个 demo 可以直接运行
https://pastebin.com/zSDjvULE

@kayseen
```
def base62_encode(deci):
s = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
hash_str = ''
while deci > 0:
hash_str = s[deci % 62] + hash_str
deci /= 62
return hash_str

if __name__ == '__main__':
num = 12837912839128347316
print(base62_encode(num))
```

https://blog.2014bduck.com/archives/241
https://blog.2014bduck.com/archives/250
同分享

@PanJiaChen 2333 我也不知道他讲的是啥 orz 尼克杨.jpg

@royzxq 谢谢 发了 不过活动什么就算了 留给其他人参与吧～

另外特别感谢 @PanJiaChen 大佬的内推，整个等待过程都不断被我骚扰进度 Orz 继续努力～再接再厉～

帮忙顶一下帖子，楼主 wx 解答问题很耐心～

@yoyos base62 方案号段会影响输出的长度，如果你要做成一次性分配完的话不方便在固定长度短链（也就是业务要求的 7 位）下水平扩容，而且复杂度并没有降低，还是要实现扩容发号那一套东西。。。

@mrlmh00 嗯看到确实是这样，但是这个问题还是非常好解决，只需要想办法将 base62 生成的信息按照特定规则编码出来增加破解难度就可以了？至于其他的生成方案，主楼已经讲过为什么不打算使用了。

当然如果有所谓的''完美''方案，也欢迎提出来交流学习～

@daquandiao2 hhhh 是的特地注册的～ me 后缀还不让备案

@mengzhuo 随机数和 mac 地址做异或，如何保证唯一性能解释下吗，个人认为这种生成器里面出现随机数的话思路就已经错掉了。。。不同 mac 地址+随机数可以保证不发生冲突吗？

@levelworm 虽然听起来可行，首先你的中心节点 /或者说生成器需要做成单实例的，因为不能多个实例同时生成，否则就会有冲突，其次中心节点分发生成后的 ID，也就是一段字符串，会有额外的流量开销（比如分发 1000w 个长度为 7 的字符串），不管大还是小，肯定是不如按号段分发计数器（只需要传输[0, 10000000]这样的范围数据），单点的服务再生成 ID 的