Mysql表设计时，完全使用自增主键ID进行应用开发和业务处理，会有什么问题吗

一、问题

发现很多表设计(包括我们的大部分主要数据库表设计)，都会有一个自定义的字符串作为业务处理字段，自增主键ID作用并不是很大，请问这样设计有没有必要性和合理性？

抛弃这一个字段完全使用自增主键ID会不会有什么缺陷？

二、解答

解答1：

自增主键要慎用。特别是数据库表自带的那种，在数据迁移和传输过程中都会带来很多问题。

很多业务主键都要设计编码规则和范围，以便于表述。比如一个物料号，你可以定义其编号范围是RAW001~RAW99，前缀RAW表示原材料，后三为是序列号。这样的编码规则有利于记录和口头传播。

有些年轻的开发者由于从前台技术入手，非常不注意数据模型的设计，喜欢用自增主键或者UUID等，这是一种很坏的习惯。一则如上所说不利于表述；二则体现其思维狭窄性，不懂从数据结构和信息处理出发的思考习惯。这种情况下，建议多读一些数据库理论知识，以拓宽自己的编程思维，改善思考定势。

解答2：

首先你要明白数据库第二范式的规定，一张表一定要有一个主键，所以在此情况下，最方便的做法就是采用自增字段作为主键，因为一张表的自然的具有唯一性的属性字段通常是无法确定的。

其次，我不太明白你所说的“一个自定义的字符串作为业务处理字段”是什么意思？如果是订单号之类的字段，那如果你能确保这个字段对于这张表是具有唯一性的，当然可以不用自增字段作为主键，而直接用这个业务字段作为主键（但实际项目中，你会体会到这个想法挺幼稚的）。而如果你只是想用一个UUID去代替自增字段作为主键，那么大可不必，因为这个UUID如果没有承载业务意义（也就把它作为订单号之类的），它会比自增ID占用更多的存储空间，而且在生成UUID时，还占用了应用服务器的CPU等资源。

最后，“完全使用自增主键ID进行应用开发和业务处理，会有什么问题吗？”当然没有问题啊，设计自增字段的目的就是为了让你把它作为主键的，因为基本上在所有的数据库引擎中，一张表只能有一个自增字段。至于说把自增字段用于业务处理，这个是取决于需求，如果需求方能接受自增字段作为订单号之类的具有业务意义的字段，当然没有问题，但如果不接受，你还是要增加字段去处理。

再提一句，就算是分布式数据库，自增ID其实方案还是挺多的，完全不用担心。

解答3：

没什么问题，只是担心数据量。而且自增的索引在很多时候提高检索效率

自增主键应该作为表的数据记录唯一标识，不应该有业务意义；

即便主键id变化，也不用担心id变化造成业务出现问题，

主键id变化情况：数据迁移，类型变更等

解答4：

没什么问题，只是担心数据量。而且自增的索引在很多时候提高检索效率

解答5：

自增主键应该作为表的数据记录唯一标识，不应该有业务意义；

即便主键id变化，也不用担心id变化造成业务出现问题，

主键id变化情况：数据迁移，类型变更等

解答6：

分表的时候会有问题。业务表最好不要用自增主键，一般采用雪花算法来做。