EF core支持多种主键生成策略：自动增长；Guid；Hi/Lo算法等。本文主要讲解这几种主键的优缺点，以及推荐使用方式。

优点：简单；

缺点：数据库迁移以及分布式系统中比较麻烦；并发性能差。long、int等类型主键，默认是自增。

EF Core新增数据自增主键值的获取：在EF Core执行savechanges保存数据后会自动把自动主键的值更新到Id属性。

代码中不能为自增字段属性Id赋值，必须保持默认值0，否则运行的时候就会报错，要想获取id值，必须借助事务，在savechange之后才能获取，代码麻烦。

Guid算法生成一个全局唯一的Id。适合于分布式系统，在进行多数据库数据合并的时候很简单。

优点：简单，高并发，全局唯一；

缺点：磁盘空间占用大。

Guid值不连续，使用Guid类型做主键的时候，不能把主键设置为聚集索引。因为聚集索引是按照顺序保存主键的，因此用Guid做主键性能差。比如MySql的InnoDB引擎中主键是强制使用聚集索引的。有的数据库支持部分的连续Guid，比如SqlServer中的MewSequentialId(),但是也不能解决问题。在SqlServer等数据库中，不要把Guid主键设置为聚集索引；在MySql数据库中，插入频繁的表不要用Guid作为主键。

程序中推荐使用Guid主键，并通过程序手动进行赋值。

EF Core支持Hi/Lo算法来优化自增列。主键值由两部分组成：高位（Hi）和低位（Lo），高位由数据库生成，两个高位之间间隔若干个值，由程序在本地生成低位，低位的值在本地自增生成。不同进程或者集群中不同服务器获取的Hi值不会重复，而本地进程计算的Lo则可以保证可以在本地高效率的生成主键值。但是Hi/Lo算法不是EF Core的标准。

混合自增和Guid（非符合主键）。用自增列做物理主键，而用Guid做逻辑上（程序中把Guid当主键使用）的主键。把自增列设置为表的主键，而在业务上查询数据的时候把Guid当主键用。在和其他表关联以及和外部系统通讯的时候（比如前段显示数据标识的时候）都是使用Guid列。不仅保证了性能，而且利用了Guid的优点，而且减轻了自增主键自增性导致主键值可被预测带来的安全性问题（网站爬虫索取网站信息）。