最近公司在进行网站的SEO优化，将所有主要页面的URL统一更改为新的格式，其中重要的一项改变是将所有URL的标识符统一为ID。
在看到设计文档（DesignDoc）的同时，我本能就对这个这样的URL形式产生了一丝疑虑，但又说不上为什么。
我们的用户信息是存在MySQL数据库的表单中，user_id是一个整数类型的主键（PrimaryKey），同时也是自增（AutoIncrement）字段。
从安全角度来说，使用user_id来作为标识符的URL设计并没有什么问题，但是这样会有别的问题，什么样的问题呢？
暴露商业数据！
暴露的数据1：总体用户数量
有心人如果想要知道公司现在的总体用户数量，那么很简单，只需要注册一个新用户，然后查看自己的公共主页，这样新用户的user_id就会暴露出来，而这个user_id就约等于网站现在的总体用户数量（有一部分被删除的用户除外）
暴露的数据2：用户增速
如果说暴露总量还不是最危险的，用户增速则是更加重大的信息暴露。
二者相减（1005000-1000000）就可以轻易得到这段时间内的用户增长量。甚至可以在外部用很小的代价获得非常精确的用户增长曲线。
而这样的数据，对于大部分公司来说，都是非常核心的数据，尤其在公司未上市之前，应该尽量避免此类数据外流。
这样的情况十分普遍，因为在学习Web开发的初级教程中，几乎都会将数据库主键ID用来作为URL标识符，这样从URl解析主键到后台服务使用主键查询数据库，可以非常简洁直观。但是在实际的生产环境中，这样的做法往往并不可取。
那么有什么样的方法可以避免使用数据库ID呢？
使用UUID——UUID是乱序的字符串，所以无法用来预测数据，我们可以用多种方法来设计UUID。
如果你使用了MongoDB等NoSQL的存储，那么恭喜你获得了天然的UUID，每一个ObjectID都是你可以使用的UUID。
如果你的数据依然离不开关系数据库，那么可以考虑在数据库中扩增字段来生成UUID并存储，同时提供基于UUID的查询接口。
加密自增ID——在系统已经到处使用自增ID作为内部查询的关键词的情况下，往往迁移到UUID会带来很大的工程开销，并且为了支持已有的URL访问，还需要维护两套不同的逻辑。
在这种情况下一种相对简便的方法是在服务器端在生成URL的时候对于ID进行加密，这样在客户端看到的便是加密后的ID。
结束语：以上就是关于为什么数据库中的ID不能作为URL的标识符的全部内容，更多内容请关注学步园。