主键的设计：

1.自增id存在的问题：

1.可靠性不高：
  1. 存在自增id回溯的问题，8.0版本进行了修复

2.安全性不高
  1. 对外暴漏的接口可以非常容易的猜测对应的信息，如：user/1这样的接口，从而对数据进行爬取

3.性能差：
  1. 自增id的性能差，需要再数据库服务器端生成

4.交互duo：
  1. 业务还需要额外执行一次类似last_insert_id()的函数才能知道刚才插入的自增值，再多进行一次网络交互，在海量的并发系统中，多一条sql就多一次性能的开销

5.局部唯一性：
  1. **最重要的一点**，自增id是局部唯一，只是在当前数据库实例中唯一，而不是全局唯一（在任意服务器间都是唯一的），在分布式系统说是噩梦

2.业务字段作为主键：不太合适

1.不能使用会员卡号作为主键

  1. 如果会员卡号不再使用注销了，就可以再给其他人用该卡号，会导致数据库中查询出该卡号的消费信息是上一个人的

2.身份证号或电话也不能作为主键

  1. 电话注销，手机也存在被运营商收回再利用的情况
  3. 身份证号属于个人隐私，也不能使用

设计主键的建议:

非核心业务：对应表的主键自增ID 如日志，监控等信息

核心业务：主键的设计应该是全局唯一且单调自增，全局唯一保证各个系统中都是唯一的，单调递增是希望插入时不影响数据库性能