数据库设计中，是不是尽量不要用自增类型做主键啊？

[I_LOVE_YS]

数据库设计中，是不是尽量不要用自增类型做主键啊？

如果A表用自增（id）作为主键，B表关联A表表时，
是通过A表的Id作为关联的，假如我不小心把A表的
记录删除了，重新追加记录，这是Id变了，还要更
新B表，那多麻烦啊！！

对不对？

[Tiger_Zhao]

不是。
如果的确要删A表记录，B表的关联记录也需要一起删除。
数据库设计不考虑“不小心”的操作，出问题自负。

[gw6328]

如果你建了外键，你是不能直接删掉这种的。会报错。 现在大数据的应用越来越多。现在慢慢的大家又开始使用主键外键了，前几年流行不建外键，主键有都不建（当然是要建索引的），因为测试这此确实很麻烦，但是现在比如做数据分析，数据同步，用一些框架如ef都要求要主键，有些地方有外键也很方便，而且数据也更安全。

[LongRui888]

关键看你的业务，如果你的业务只需要一个递增的值，那么就用自增列就可以了，如果你要实现那种 有意义的流水号，那就要自己生成id了。 另外，你把这个自增列做成主键，而子表中引用这个id做外外键，可以设置级联删除，一旦删除了主表的id，那么子表也会自动删除相应的记录，就可以了。

[Ny-6000]

是的,关键看要求决定了.

[卖水果的net]

使用 FK ，想删的话，必须先删 B 表数据，再删 A 表。

[I_LOVE_YS]

谢谢大家都指导，学习很多。 贴别是说道自增类型在做分布式存储时， 会引起冲突的问题，真的提醒了我。

[Tiger_Zhao]

存储设备的分布式储存不影响数据库的自增啊，存储对数据库是完全透明的。
如果是指多个分部（服务器）插入的数据需要合并，完全可以设置各自的id范围（起始seed的不同）来避免重复啊。

[ChinaITOldMan]

引用 6 楼 yupeigu 的回复:

关键看你的业务，如果你的业务只需要一个递增的值，那么就用自增列就可以了，如果你要实现那种 有意义的流水号，那就要自己生成id了。 另外，你把这个自增列做成主键，而子表中引用这个id做外外键，可以设置级联删除，一旦删除了主表的id，那么子表也会自动删除相应的记录，就可以了。

I agree with you

[许晨旭]

用自增列一旦自增列有问题会很麻烦，一般用uniqueidentifier 这个是每个电脑每次生成的都不一样你可以试试这个

select newid()

[Cherise_huang]

也不是，这要看具体情况的 自增做主键的坏处目前没有发现，但如果是分布式储存的话，有可能会出现冲突。 为了避免上述情况出现，在分布式存储时，可以使用GUID做主键——带来的副作用是性能下降，因为生成一个GUID肯定没生成一个自增长的ID快

[zbdzjx]

我之前写的系统是用的自增ID做主键，但在B表中，会相应的建外键，这样，在删除A表的记录时，会进行检查，防止乱删、删错。