所以这个问题听起来可能有点深奥，但我注意到了一些"神奇"的东西，我担心引擎盖下发生的事情的性能。假设我使用TPC设计创建实体，所有实体都继承(直接或间接)根基实体，并且根基实体包含全局唯一标识符(如Guid)，该标识符在保存之前在代码中生成(即，不是由数据库生成)。
我希望以下代码通过查询与协同通用类型相关的表来返回一个类型化的动态代理(它确实这样做了)：
context.Set<ConcreteDerivedEntityClass>().Find(someGuid)
然而，我也注意到我可以执行以下操作：
context.Set<BaseEntityClass>().Find(someGuid)
这非常酷，并且会神奇地为正确的具体类的请求Id返回一个类型化的动态代理。EF怎么知道Id属于哪个派生类/表？它是否会查看它所知道的每一个表/实体类型，直到找到匹配项(因此是性能问题)？
继承表/实体的主键也是指向基表的外键。
然后它所需要做的就是查看从基类继承的类。它可能也会在加载时将关系缓存在内存中的某个位置，以避免每次调用时反射对性能的影响，因为关系是运行时静态的。
剩下的就是查询与子类名称匹配的表。这将是一个聚集索引查找，因为需要继承。因此，尽管存在性能损失，但考虑到您获得的抽象性，这是微不足道的。
编辑：
BY默认代码首先使用"每层次表"(TPH)，这是一个非规范化的表，实体类型编码在Descriminator列中。在这种情况下，列告诉EF将结果类型转换到哪个实体中。
上面提到的TPC需要DBContext中的额外代码来指定正确的表映射。它可能会将其缓存在内存中，并运行上面已经描述过的例程。