大家的数据库主键 ID 是用什么？

[zealinux]

1. 自增长的 Long 或 Int
2. UUID
3. 自己代码生成插入 String

或者其他更好的方案

---

我喜欢用 UUID，这样每次合并数据时没那么痛苦。

[CCIP]

雪花算法

[FanError]

用 UUID，不过一直看别人说性能不好。
我寻思着接触的项目应该数据量或对性能的要求还没达到要在这个 UUID 上榨性能的地步，就没管了。

[asAnotherJack]

自增，索引的原理 用自增的好

[tabris17]

那还不如 snowflake

[Cmdhelp]

这个还是看应用环境吧，

[ytmsdy]

自增，毕竟时不时查数据，看 ID 的时候，长长的 UUID 看多了眼镜会瞎。

[MeteorCat]

自增 ID，很多项目都达不到研究选用什么主键 ID 的地步，按照最简原则选择最容易的

[littleylv]

量大再考虑性能。
量少，喜欢用什么就用什么

[arthas2234]

这个要看表的作用啊，难道订单、用户、客户数据也用自增？

[ajaxfunction]

一直是自增，目前最悠久的一个项目自增到 90 万

[Veneris]

雪花算法，自增，不连续，全局无重复。
但是太长，有没有满足以上三条但短一些的。

[gjquoiai]

ulid https://github.com/ulid/spec

[littlewing]

@arthas2234 是的，都用自增，然后订单、用户、客户 id 加索引

[akira]

表主键 ID 用自增，原则上不参与任何业务逻辑，放着好看的。
业务 主键 用 uuid

[gz911122]

@arthas2234 是的 都用自增,恭喜你猜对了

[xsm1890]

innodb 自增

[jzmws]

无脑推荐雪花算法 太香了

[newtype0092]

@arthas2234 用啊

[Hanggi]

自增加 hash

[newtype0092]

@arthas2234 哈哈你看这么多用的，小数据量的自增最高效，大数据量或着跨库的时候用自己定义的 id 就行，自增 id 也是要保留的。

[wellsc]

@Veneris 美团的 leaf 了解一下

[gemini767]

自增 id uuid 是全局唯一 id 俩不一回事，不冲突

[keshawnvan]

自己实现的 SnowFlake： https://juejin.im/post/5e9d402df265da48094da80d

[cigarzh]

snowflake

[Eirxxx69]

不考虑性能和数据量，用啥都行

[Kenyore]

UUID 多舒服。

[xuanbg]

@FanError 对的，确实性能不好，但我们的业务每天新增的数据都是以百千计而非百万千万计……所以我就不管他性能好不好了，只要用的方便就好。真香

[creatdate]

UUID，因为同时插多张表，UUID 一致正好可以关联，单表就随便，自增比较方便。

[sunmoon1983]

@jzmws 雪花是很香，但是需要把数据交给 js 的时候就不香了，还需要转成字符串

[ck65]

自增和雪花并存。还蛮香的。

[beginor]

雪花 ID

[guoziyan]

说用 UUID 的，都没想过大的主键导致索引树高度的膨胀而导致查询性能的下降，同时 UUID 的随机写导致索引节点的不断分裂合并所带来的影响吗？
通常来说，在数据行 1k 大小的时候，一个三层的索引，主键使用 bigint，可以存储大约 2200w 的数据，如果是 int 的话，则能存储 4000w 左右的数据， 而 uuid 只能存 250w 左右的数据。

[PopRain]

@guoziyan 1.uuid 有升序方案 2.看应用场景，大部分应用的索引不会很在意你说的性能区别，只是心理上的差别

[huobazi]

snowflack

[MarsBar]

uuid v5 hash 某些字段 然后拿来当主键。。

[guoziyan]

@PopRain 如果对性能没有吹毛求疵要求的话，也不是不能接收。

[sprit]

主键自增 业务 ID snowfalck

[MOONLIGHTT]

分布式用雪花，单机用自增 id

[yeqizhang]

@creatdate 一对一主键关联我见过用 int 的……