因为原来都是使用mongodb 的id 作为业务id。目前准备使用Mysql 并选择了Innodb引擎。在这个前提条件下。 目前准使用数据库自增id 作为物理主键来提高Innodb对索引的维护性能。
现在，假设目前有一张用户表，那么用户id 该怎么生成。不希望使用主键自增id 作为业务id。因为比较容易被猜到和暴露业务信息。 所以现在暂定方案 是使用snowflake算法生成的id 作为业务id。比如用户id。使用mysql自增id 作为物理主键，来标识数据。 想请教下 大家，这种方案有没有什么问题。
snowflake算法一般用于分布式的id生成哈， 如果只是为了不让id暴露，上雪花感觉比较浪费 你可以给url上的id做hash，然后写个中间件解析数字到代码就好了。 node也有hashid这个库能进行此类操作
@PerfectDemo 谢谢指点。不是仅为了不让id 暴露，还希望业务id 具有一点可读性和随机性和唯一性，比如像mongodbid那种16进制就挺合适的。找了下看起来snowflake id 看起来也比较合适。但现在讨论后 业务端希望id 都是stirng类型的。按照这种要求 准备用snowflake id 生成出来的8字节的long转存string 作为业务主键存储，但这样用感觉也有点怪。
@CollapsarLi 轮子 https://github.com/waitingsong/koid/ snowflake id 是 Int64，数据库可以使用 int8 字段保存，应用层传输可以转换成 string （如果返回 JSON 类型，那么也得先转成 string 类型。因为 JSON 目前不支持 LONG 类型）。 还可以当 request-id 使用： https://github.com/fsd-nodejs/service-mw2/blob/master/src/app/middleware/request-id.ts
@waitingsong 感谢
那也可以继续用mongoid啊😂
https://github.com/mongodb/js-bson/blob/master/src/objectid.ts
@abiuDoIT 是的，简单粗暴直接用mongoid就完事了，但现在还是得仔细想想，埋坑后面就难弄了。