主键不可修改
对于数据库来说，主键其实是可以修改的，只要不和其他主键冲突就可以。但是，对于应用来说，如果一条记录要修改主键，那就会出大问题。
因为主键的第二个作用是让其他表的外键引用自己，从而实现关系结构。一旦某个表的主键发生了变化，就会导致所有引用了该表的数据必须全部修改外键。很多Web应用的数据库并不是强约束（仅仅引用主键但并没有设置外键约束），修改主键会导致数据完整性直接被破坏。
业务字段不可用于主键
所有涉及到业务的字段，无论它看上去是否唯一，都决不能用作主键。
主键必须使用单独的，完全没有业务含义的字段，也就是主键本身除了唯一标识和不可修改这两个责任外，主键没有任何业务含义。
类似的，看上去唯一的用户名、身份证号等，也不能用作主键。对这些唯一字段，应该加上unique索引约束。
主键应该用什么类型
主键应该使用整数还是字符串？
我强烈建议使用字符串。
为什么？
我们先看使用整数的问题。
使用整数有两个选择：数据库自增和自己生成。
自己生成其实也是自增，无非就是把上次使用的值保存到某个地方，下次使用的时候继续自增。常见的做法是用一个单独的表存储上次用的最大值。这种方式实现复杂，可靠性低，还不如数据库自增。
数据库自增最大的问题还不在于数据库单点造成无法水平切分，因为绝大部分公司还撑不到业务需要分库的情况就倒闭了。
自增主键最大的问题是把公司业务的关键运营数据完全暴露给了竞争对手和VC。举个例子，用户表采用自增主键，只需要每周一早上去注册一个用户，把上周注册的ID和本周注册的ID一比，立刻就知道了该公司一周的新增用户数量。如果网站声称新增了10万用户，但ID却只增加了1千，就只能呵呵了。
因为主键的本质是保证唯一记录，并不要求主键是连续的。实际上不连续的更好，这样既避免了运营数据泄露，也给黑客预测ID制造了障碍，具有更高的安全性。
用字符串主键就不存在这个问题。如果我们用一个UUID作为主键，即varchar(32)，除了占用的存储空间较多外，字符串主键具有不可预测性。
有人觉得UUID完全随机，主键本身没有按时间递增，不利于直接主键排序。其实解决这个问题很简单。
方法一，直接用时间戳+UUID构造一个主键，时间戳注意补0，这样生成的主键就是按时间排序的。这个方法简单粗暴，缺点是主键更长了。
方法二，自定义一个算法，时间戳放高位，序列号放低位，还可以保留机器位，然后用base32编码，可以把长度控制在20个字符内。
