如何获取数据库id从某大厂的URL去看数据库自增ID

导读某大厂用户访问URL之前在用pholcus在做数据收集时候，发现个某大厂的URL，当时有点小意外吧。https://www.xxxxxxxxxxx/u/ss....某大厂用户访问URL

之前在用pholcus在做数据收集时候，发现个某大厂的URL，当时有点小意外吧。

https://www.xxxxxxxxxxx/u/ssssssssss?is_hot=1#_loginLayer_xxxxxx注：ssssssssss为十位数的数字，原数字经过百度查询能查询到该用户，这里避嫌下。

从这个URL出发，前端路由有可能使用vuex router实现的，而且槽点有不少。首先，你会猜测ssssssssss会是什么，看到/u，瞬间就明白了，它是个用户ID，而且极有可能是 AUTO_INCREMENT ID。然后按这个逻辑，把3295362810换成1、1111111111、1111111112再去访问，结果如下：

https://www.xxxxxxxxxxx/u/1 404https://www.xxxxxxxxxxx/u/1111111111 200https://www.xxxxxxxxxxx/u/1111111112 200

也不知道，你是否干过这事，数据库ID自增，下标改成1亿开始的。其实，还有一个槽点，我当时加个page查询参数，没想到行得通。而且，这个大厂有个要求非登录用户，不能浏览当前用户的下页，只能浏览首页。现在看来，对程序员来说，形同虚设。

https://www.xxxxxxxxxxx/ssssssssss?is_hot=1&page=2 200

对外提供用户ID查询接口，中间也不加密转换处理，实属不该。

可以参考下Google下一页的做法，对外url会有一层转换，而不是直接使用查询参数page

请弃用数据库自增ID

使用数据库自增ID，有个好处，简单快捷递增，使用innodb聚集索引，性能更好。但是，这里还是建议弃用，它有如下劣势：

1. 信息泄露，就像上面的URL一样，很容易让人猜到这个是ID并且自增；
2. 数据实体被遍历枚举的风险，如爬虫可以根据自增ID设置遍历规则；
3. 与其他实体ID无辨识度；
4. 强依赖DB，当DB不可用时导致系统不可用；
5. 在异库异构、分表分库的情况下，新旧系统交接或并行运行，数据同步将会是噩梦；

在这里，推荐下美团分布式ID生成系统Leaf（https://github.com/zhuzhong/idleaf），并且有很详尽的学习和使用文档。