短网址都会有一串随机的短码，如果直接使用保存原始 url 的数据库主键 id 会有什么问题

[iCD]

假设短链服务时 dl.c

db 设计为

id	rawurl
1	www.baidu.com

我创建 www.baidu.com 的短链就直接写一条单纯的 url 记录，然后以主键 id 作为 dl.c 的短码，

请求 dl.c/1 直接查 id 为 1 的 rawurl 进行重定向，这样有啥问题吗？

目前能想到的就是会被别人遍历，但是好像也没啥问题？

id 用 bigint 也足够用

[Jooooooooo]

公开 id 不应具备可遍历属性

[FS1P7dJz]

提问
那么当别人在此使用你的服务生成一个一样的 www.baidu.com,你是变成 dl.c/2 还是继续 dl.c/1 呢?

再提问
如果你稍微需要做一些统计服务,那么 dl.c/1 和 dl.c/2 都是统一个网址,你又如何进行合并呢?

继续提问
如果是 baidu.com/1.html 和 baidu.com/2.html,你又如何进行统计呢?

以上都是基于亿级数据考虑

不过如果你只是造个自己用的轮子...倒也无妨考虑这么多

[imdong]

自己用，完全没问题。

短网址核心代码无非就这么几行。
保存对照表，以及取出数据并跳转。

其余的一切都是基于安全性，速度等角度进行的优化罢了。

考虑到数据越来越多，会将 10 进制进行 62 进制转换以缩短链接。

数据量越来越多，会使用缓存等方式优化查询速度等。

[wunonglin]

https://hashids.org/

[opengps]

我就是这么用的，不过我不是用的 int，而是自己指定

[6IbA2bj5ip3tK49j]

int 不够短，本身就和短链接相违背了。

[iCD]

@FS1P7dJz 学习了。

请问这里讲的统计一般是个什么样的需求呢？
如果不需要对短链进行分析的话 长链和短链应该是一一对应就可以？

[iCD]

@xgfan @imdong 是的 我刚也想到这个原因了，数据量大了之后这个主键 id 长度会变的越来越长，而且长度不固定。
通过转成 62 进制就能变短且固定

[felinx]

用 hashid 啊，够短且不能被遍历的 https://hashids.org/