使用ef核心时有什么好的继承策略？当前，我们有一个带有主键的抽象BaseEntity类，一个创建和修改的日期以及一些有关创建者的字段。 5个抽象类从该BaseEntity继承，并且80多个类扩展了这些抽象类。 结果是一个巨大的BaseEntity表，我们现在正面临着mysql表上的索引数量限制（64个索引）。 对于每个fk，我们都有一个索引。我非常担心这张巨型桌子的性能。如果我们在此表中存储10个Country对象和10亿公民。我的查询GetAllCountries是否会遭受同一表中所有非国家/地区对象的困扰？ （我们的标识符是字节）
我们可以更改模型，但这将是一个非常昂贵的模型，并且由于我们在ICollections中大量使用了抽象类，因此感觉很奇怪。我们甚至与我们的BaseEntity有多对一的关系。例如，一个ActionHistory项包含一个BaseEntity。
我们可以重新编译数据库（mariadb），并将最大索引数更改为128。
或者我们可以从表策略（tpt）更改。但是接下来我们需要一个不同的规则。由于Ef核心仅支持每个层次结构的表。相当昂贵。而且我不知道这会对性能产生什么影响。
我希望我们在模型或流畅的api配置中犯了严重错误。因为我无法想象所有更大的ef核心项目都面临这个问题。