一般用户表的用户 ID，是不是设计成字符串的比较多

整数自增问题用户容易被爬虫遍历吧，比如你是 id1 ，我是 2 ，只要一个个试过去就行了

@BeforeTooLate 不成熟的想法，自增一个比较大的素数就行了。uint64 溢出也不要紧，正好相当于取模了

unsigned uint64 自增
多库分布系统就他自己自增 然后复合唯一索引带 node_id ，合并一起做 userid

@BeforeTooLate
数据库 ID 和前端显示 ID 为什么要统一？
发送前和获取后过一个 o(n)复杂度的简单变换，别人不知道算法就完事

数据库查询用 bigint ，对外输出 hashid

职业生涯遇到过好几次数据库迁移，得到的教训就是数据库尽量不要用自增 id ，不然迁移表数据简直是灾难

区分 uid 和 uname 就行

@BeforeTooLate 平时写接口注意点，带上当前登录人的标记去数据库查，只查当前登录人的信息，不就避免被刷了吗。这样的思路很多

用户 id 直接数据库自增？都不分表的吗？

整型自增，对外加密，就像微信的 openid 一样，虽然不清楚具体实现，但应该是可以解密得到整型自增 uid 的

@ccagml 分库分表也可以自增呀，例如百库十表，取 uid 低 10 位标识在哪个表，右移 10 位得到在具体表中的自增 id

bigint ，然后对外 hashid

用了很多年 uuid ，完全代替了自增数字，并且封装在所有使用过的框架中
除了一点点性能问题，好像没什么缺陷了吧

看需求吧。。

首先看你这个用户 id 定义成什么，还有就是个人习惯，公司习惯，代码项目习惯啥的。

有的是 us-xxxxx ；有的是 uuid ；有的是自增数；有的是长整数，这和 是不是字符串都没关系。。。

你想问的是数据库的实现，和 用户 id 设计没啥关系。。数据库层面，一般用 固定 char 就行。。你数据库存成数字有什么优势么？你想一想

然后再解释下自增 id：自增 id 相当于把 id 生成的事情扔到 db 了。看你们个人习惯和项目习惯，不是不可以。如果数据关联的逻辑也扔给 db ，这么做都没啥问题。

其实都挺新手的问题，大概能猜到 op 工作环境。

无脑雪花主键啊。。UUID 不建议，太长和分散，不适合索引

@zhaogaz 你牛逼，这都能扯到工作环境

为了防爬虫丢掉自增 ID 有点小题大做了，用户量不大的话完全可以给进出 API 接口的自增 ID 跑个对称加密，防爬+性能兼得。这年头 AES 加解密的开销比 DB lookup 一个字串 ID 小多了。

用字符串作为 ID 的要注意一下数值特别大的情况，接口返回 JSON 格式时要用程序转成字符串，别超过最大安全数。吃过这方面的亏

@b821025551b 主键都是聚簇索引，都排好序的，为啥会影响读性能？