我正在使用具有大量模型之间关系的相当复杂的模型构建日历/条目/统计应用程序。
一般来说，我关心性能，正在考虑不同的策略，并在实现应用程序之前寻找输入。
我完全是新手，DBContextPooling所以请原谅我可能提出的愚蠢问题。但是DBContextPooling与使用多个类有什么关系DBContext，或者使用是否与提高性能有关，无论是单个还是多个DBContext？
我最终可能会实施更多的DBsets，还是应该避免它？为了简单起见，我正在考虑创建多个DBContext类，但这会减少内存使用并提高性能吗？将应用程序拆分为更小的项目会更好/更智能吗？
IEnumerable使用vs有任何性能差异ICollection吗？我尽可能避免使用列表。或者使用起来会更好IAsyncEnumerable吗？
您的大部分性能痛点将来自您尚未简化的复杂架构。当一个用例踩到另一个用例并且您的关系如此交织时，管理单一应用程序会导致许多不必要的“补偿”逻辑。
诸如是否使用上下文池或 IEnumerable 与 ICollection 之类的优化可以稍后进行。它们不应影响您的解决方案的架构。
如果您的项目像您建议的那样复杂，那么我建议您阅读领域驱动设计和微服务并将您的应用程序分解为多个项目（或项目组）。
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/
每个项目（或项目组）都有自己的 DbContext 来管理该项目中的实体。此外，每个 DbContext 都应该从仅通过 DbSet 公开聚合根开始。这可能意味着比特定用例严格需要更多的数据库活动，但最好从一个干净的架构开始，并在需要时压缩最后一盎司的性能（有时以架构清晰度为代价）。
例如，如果您想将与会者添加到约会中，直接攻击与会者表可能会很有吸引力。但是，为了保持干净，考虑到没有约会就不能存在与会者，那么您应该将约会作为聚合根，并且只将约会暴露为外界攻击的切入点。可以从数据库中检索到该约会及其参加者。然后要求约会添加与会者。然后通过调用 DbContext 上的 SaveChanges 来保存约会图。
总之，您的约会负责其图表中的功能。您应该让 Appointment 将与会者添加到列表中，而不是将与会者添加到 Appointment 的与会者列表中。思维的微妙转变可以大大降低解决方案的复杂性。
艺术正在决定微服务/上下文之间的边界应该在哪里。两种不同的架构各有利弊，没有明显的赢家
对于您的其他问题：
DbContext 池是关于维护一个随时可用的实例化 DbContext 池。它节省了重复 DbContext 实例化的开销。可能不值得，除非您收到大量单独的请求，并且您的分析表明这是一个痛点。
上面提到了所需的 DbSet 数量。
至于 IEnumerable 或 ICollection 或 IList，这取决于您需要什么功能。这是一个很好的简单总结...... https://medium.com/developers-arena/ienumerable-vs-icollection-vs-ilist-vs-iqueryable-in-c-2101351453db
将应用程序拆分为更小的项目会更好/更智能吗？
是的，一点没错！从架构清晰度开始，然后在需要的地方和时间调整性能优势。不要以性能为目标（除非您正在构建毫秒敏感的解决方案）。