EF Core数据库优先模式下替代主键与Find方法使用问题咨询

首先先还原你的场景和遇到的问题：

我通过dotnet ef dbContext scaffold以数据库优先方式生成了EF Core模型。数据库使用自增整数主键用于表关联，但存在一个基于字符串的唯一索引，作为查询表的合理索引。然而，当我调用FindAsync("abc000")时，出现预期内的错误：“The key value at position 0 of the call to 'DbSet.Find' was of type 'string', which does not match the property type of 'long'”。现咨询三个问题：

1. EF Core是如何识别主键的？
2. 能否在保留自增主键的前提下，调整配置使Find方法可通过字符串Key查询实体？
3. 优先使用自增整数主键作为表关联字段是否合理？

你的相关代码与建表语句 #

实体类

class Entity { long Id; string Key; };

OnModelCreating配置

modelBuilder.Entity<Entity>(entity => {
    entity.ToTable("tb_entity", "main");
    entity.HasIndex(e => e.Key)
        .HasName("uq_entity_key")
        .IsUnique();
    entity.Property(e => e.Id).HasColumnName("_id");
    entity.Property(e => e.Key)
        .HasColumnName("key")
        .HasMaxLength(255);
}

建表SQL

CREATE TABLE [tb_entity] (
    _id BIGINT PRIMARY KEY IDENTITY(1,1),
    key NVARCHAR(255) CONSTRAINT uq_entity_key UNIQUE NOT NULL,
);

1. EF Core是如何识别主键的？ #

EF Core识别主键主要靠约定、数据注解、Fluent API，再结合数据库优先模式下的数据库元数据读取，具体逻辑如下：

• 约定优先：默认会把命名为Id或者[实体名称]Id的属性识别为主键，比如你的Entity类里的Id属性就符合这个约定。
• 数据库元数据：因为你是数据库优先模式，EF Core会直接读取数据库表的主键约束——你的_id字段在数据库里被标记为PRIMARY KEY，所以scaffold时，EF Core会把对应的Id属性映射为主键，哪怕你用HasColumnName("_id")做了属性名和列名的映射。
• 显式配置：如果约定不满足，你也可以用[Key]数据注解，或者Fluent API的entity.HasKey(e => e.Id)来强制指定主键。

在你的场景里，EF Core就是通过数据库的主键约束+属性命名约定，把Id（对应数据库_id）识别成了实体的主键。

2. 能否在保留自增主键的前提下，调整配置使Find方法可通过字符串Key查询实体？ #

这里要明确一点：FindAsync方法是EF Core专门为主键查询设计的，它的逻辑是先查DbContext的本地缓存，再查数据库，而且只能接收主键类型的参数。所以你没办法直接修改Find方法的行为，让它用非主键的Key来查询。

不过你可以自己实现一个类似Find功能的自定义方法，来达到通过字符串Key查询实体的目的，比如在你的DbContext里添加一个方法：

public async Task<Entity?> FindByKeyAsync(string key)
{
    // 先检查本地缓存，和Find的逻辑保持一致
    var localEntity = Set<Entity>().Local.FirstOrDefault(e => e.Key == key);
    if (localEntity != null)
    {
        return localEntity;
    }

    // 缓存里没有就查数据库
    return await Set<Entity>().FirstOrDefaultAsync(e => e.Key == key);
}

这个方法和Find的逻辑对齐，既利用了本地缓存提升性能，又能通过业务唯一键查询实体，完美满足你的需求——而且完全保留了自增主键的配置。

3. 优先使用自增整数主键作为表关联字段是否合理？ #

非常合理，这也是业界的通用最佳实践，原因主要有这几点：

• 性能优势：整数类型（比如你用的BIGINT）的存储体积小，索引效率高，关联查询时的JOIN操作速度远快于字符串类型，能显著提升数据库的整体性能。
• 稳定性强：自增整数是数据库自动生成的，不会出现字符串可能遇到的拼写错误、格式变更、长度不一致等问题，作为关联字段非常可靠。
• 兼容性好：几乎所有关系型数据库都支持自增整数主键，EF Core等ORM框架对整数主键的支持也最完善，很少会出现兼容性问题。
• 数据冗余少：关联表中存储整数外键比字符串外键占用的空间少得多，能有效减少数据冗余，降低存储成本。

而你的字符串唯一键Key，非常适合作为业务查询入口（比如根据业务标识查询实体），但不适合作为关联字段——你现在的设计（自增整数主键+字符串唯一索引）是典型的“技术主键+业务唯一键”的合理架构，两者各司其职，完全没问题。

内容的提问来源于stack exchange，提问作者Chris Becke